From publicity-bounces@lists.xenproject.org Tue May 05 11:25:18 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 11:25:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpayS-0005GS-Tm; Tue, 05 May 2015 11:25:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpayR-0005GN-Kz for publicity@lists.xenproject.org; Tue, 05 May 2015 11:25:15 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id FB/7E-17455-A98A8455; Tue, 05 May 2015 11:25:14 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1430825112!12342770!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25593 invoked from network); 5 May 2015 11:25:13 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 11:25:13 -0000 Received: by wgiu9 with SMTP id u9so15907616wgi.3 for ; Tue, 05 May 2015 04:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ST0WpsKvYCHQd7n6315/gtmyf8TXJ5nakzhphTm3rPc=; b=iN1S6tLdhZprdWef3WztSz7aaSovSWeDYWn9pRL4ffVKn2txOoSwMAzkyrPoqdkntm fFFToiwaXn0hkU3wxs6Ym0xUxEs7R6yIqYJ/9auAvbCrjNtDjc+HZPwl34ztm+G6esgb zli1RrMvV1mE+Ve8DbUCYBhVwlsLc91MtpPscd1ea4fZxEx/l9Vvs39UEGwdsbXNa8uw EGLVK/NVLubHb9YiCQSuUK24sf8aqp7jYMMCEaahQyGREEDQ4el0RvlDI5gu8MjXdpJJ e8vS6dzQ6Oxxz/0/y1T+oiTO5quOPlhlEYg38uw40UeV2yWpj0Ux9ZqyyCpxQgBugLkl nAoQ== X-Received: by 10.180.7.169 with SMTP id k9mr3176186wia.70.1430825111715; Tue, 05 May 2015 04:25:11 -0700 (PDT) Received: from [192.168.0.8] (97e3cdda.skybroadband.com. [151.227.205.218]) by mx.google.com with ESMTPSA id fa8sm15672953wib.14.2015.05.05.04.25.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 04:25:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> Date: Tue, 5 May 2015 12:25:09 +0100 Message-Id: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> References: <21624.43602.459298.658726@mariner.uk.xensource.com> <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> To: Tim Mackey X-Mailer: Apple Mail (2.2098) Cc: George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7331225575796891851==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============7331225575796891851== Content-Type: multipart/alternative; boundary="Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14" --Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This came up again this time.=20 =46rom Wei: > FWIW I had an informal chat with the organiser and he told me this > format was indeed new to most Intel attendants. Another thins is that > the word hackathon was misleading because they were thinking about > coding and some (many?) engineers set up development environment = before > hand. So we should change the name * Xenvolution we can't use for trademark reasons * Xen Project Architecture Design and Deployment Summit is too long So I suggest we either go for "Xen Project Architect & Design Summit" or = "Xen Project Design Summit" If there are no objections, I will make a proposal to xen-devel@ and = other lists Regards Lars > On 2 Dec 2014, at 18:56, Tim Mackey wrote: >=20 > A thought to cover the various perspectives potential attendees have, = and crisply define why they should be there: > =20 > Xenvolution =E2=80=93 The Xen Project Architecture, Design and = Deployment Summit=20 > =20 > =20 > From: publicity-bounces@lists.xenproject.org = [mailto:publicity-bounces@lists.xenproject.org] On Behalf Of Sarah = Conway > Sent: Tuesday, December 02, 2014 1:44 PM > To: Konrad Rzeszutek Wilk > Cc: Lars Kurth; George Dunlap; publicity@lists.xenproject.org > Subject: Re: [Publicity] Another reason why our "hackathons" should be = called something else > =20 > Could always pair this catchy phrase with a longer, more formal title. = Use the short one-word title in some cases (social media); longer one = when necessary to communicate to different audiences or new audiences.=20= > =20 > Xenvolution: Architect, Design & Develop Meetup/Summit/Event=20 > =20 > Xenvolution - Annual (or Biannual) Xen Project Architect & Design = Summit=20 > =20 > Just a suggestion.=20 > =20 > =20 > =20 > On Tue, Dec 2, 2014 at 1:23 PM, Konrad Rzeszutek Wilk = > wrote: > On Tue, Dec 02, 2014 at 06:00:25PM +0000, Lars Kurth wrote: > > Some more ideas for names > > Design Summit > > Architecture & Design Summit >=20 > Xenvolution sounds pretty awesome :-) > > > > Lars > > > > On 2 Dec 2014, at 17:22, George Dunlap > wrote: > > > > > [Replies inline] > > > ________________________________________ > > > From: publicity-bounces@lists.xenproject.org = = [publicity-bounces@lists.xenproject.org = ] on behalf of Konrad = Rzeszutek Wilk [konrad.wilk@oracle.com ] > > > Sent: 02 December 2014 17:07 > > > To: Amir Chaudhry > > > Cc: Lars Kurth; publicity@lists.xenproject.org = > > > Subject: Re: [Publicity] Another reason why our "hackathons" = should be called something else > > > > > > On Tue, Dec 02, 2014 at 04:26:21PM +0000, Amir Chaudhry wrote: > > >> While calling them 'Meetings' might appeal to industrial partners = (a work-related, expensable visit?), it might turn off potential = attendees. > > >> > > >> Of course, you could just call the same event different things = for different audiences. > > > > > > Huddle Meeting? > > > Brainstorms? > > > > > > [George] Architecture storm? > > > Xenvolution? (Xen + evolution)? > > > > > > Really, "summit" is probably the best word, but "Xen Summit" = already means something else... > > > > > >=20 > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity = >=20 >=20 > =20 > --=20 > Sarah Conway > PR Manager > The Linux Foundation > sconway@linuxfoundation.org > (978) 578-5300 Cell > Skype: sarah.k.conway --Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This came up again this time. 

=46rom Wei:
> FWIW I had an informal = chat with the organiser and he told me this
> format was indeed new = to most Intel attendants. Another thins is that
> the word hackathon was = misleading because they were thinking about
> coding and some (many?) = engineers set up development environment before
> hand.

So we should change the name

* Xenvolution we can't use for = trademark reasons
* Xen Project Architecture Design = and Deployment Summit is too long

So I suggest we either go for "Xen = Project Architect & Design Summit" or "Xen Project Design = Summit"

If = there are no objections, I will make a proposal to xen-devel@ and other = lists

Regards
Lars

On = 2 Dec 2014, at 18:56, Tim Mackey <Timothy.Mackey@citrix.com> wrote:

A thought to cover the various = perspectives potential attendees have, and crisply define why they = should be there:
 
Xenvolution =E2=80=93 The Xen Project = Architecture, Design and Deployment Summit 
 
 
From: publicity-bounces@lists.xenproject.org [mailto:publicity-bounces@lists.xenproject.org] On Behalf = Of Sarah Conway
Sent: Tuesday, December 02, 2014 = 1:44 PM
To: Konrad Rzeszutek Wilk
Cc: Lars Kurth; George Dunlap; = publicity@lists.xenproject.org
Subject: Re: [Publicity] Another = reason why our "hackathons" should be called something else
 
Could always pair this catchy phrase with = a longer, more formal title. Use the short one-word title in some cases = (social media); longer one when necessary to communicate to different = audiences or new audiences. 
 
Xenvolution: Architect, Design & Develop = Meetup/Summit/Event 
 
Xenvolution - Annual (or Biannual) Xen Project = Architect & Design Summit 
 
Just a suggestion. 
 
 
 
On Tue, Dec 2, 2014 = at 1:23 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
On = Tue, Dec 02, 2014 at 06:00:25PM +0000, Lars Kurth wrote:
> Some more ideas for names
> Design = Summit
> Architecture & Design Summit

Xenvolution sounds pretty awesome :-)
>
> Lars
>
> On 2 Dec 2014, at 17:22, George = Dunlap <George.Dunlap@citrix.com> wrote:
>
> > [Replies inline]
> > = ________________________________________
> > = From: publicity-bounces@lists.xenproject.org [publicity-bounces@lists.xenproject.org] on behalf of = Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
> > Sent: 02 = December 2014 17:07
> > To: Amir Chaudhry
> > Cc: Lars Kurth; publicity@lists.xenproject.org
> > = Subject: Re: [Publicity] Another reason why our "hackathons" should be = called something else
> >
> > On = Tue, Dec 02, 2014 at 04:26:21PM +0000, Amir Chaudhry wrote:
> >> While calling them 'Meetings' might appeal to = industrial partners (a work-related, expensable visit?), it might turn = off potential attendees.
> >>
> = >> Of course, you could just call the same event different things = for different audiences.
> >
> > = Huddle Meeting?
> > Brainstorms?
> = >
> > [George] Architecture storm?
> > Xenvolution?  (Xen + evolution)?
> >
> > Really, "summit" is = probably the best word, but "Xen Summit" already means something = else...
> >
>

_______________________________________________
Publicity mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= /a>


-- 
Sarah Conway
The Linux = Foundation
sconway@linuxfoundation.org
(978) 578-5300  Cell
Skype: =  sarah.k.conway

= --Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14-- --===============7331225575796891851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============7331225575796891851==-- From publicity-bounces@lists.xenproject.org Tue May 05 11:25:18 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 11:25:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpayS-0005GS-Tm; Tue, 05 May 2015 11:25:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpayR-0005GN-Kz for publicity@lists.xenproject.org; Tue, 05 May 2015 11:25:15 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id FB/7E-17455-A98A8455; Tue, 05 May 2015 11:25:14 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1430825112!12342770!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25593 invoked from network); 5 May 2015 11:25:13 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 11:25:13 -0000 Received: by wgiu9 with SMTP id u9so15907616wgi.3 for ; Tue, 05 May 2015 04:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ST0WpsKvYCHQd7n6315/gtmyf8TXJ5nakzhphTm3rPc=; b=iN1S6tLdhZprdWef3WztSz7aaSovSWeDYWn9pRL4ffVKn2txOoSwMAzkyrPoqdkntm fFFToiwaXn0hkU3wxs6Ym0xUxEs7R6yIqYJ/9auAvbCrjNtDjc+HZPwl34ztm+G6esgb zli1RrMvV1mE+Ve8DbUCYBhVwlsLc91MtpPscd1ea4fZxEx/l9Vvs39UEGwdsbXNa8uw EGLVK/NVLubHb9YiCQSuUK24sf8aqp7jYMMCEaahQyGREEDQ4el0RvlDI5gu8MjXdpJJ e8vS6dzQ6Oxxz/0/y1T+oiTO5quOPlhlEYg38uw40UeV2yWpj0Ux9ZqyyCpxQgBugLkl nAoQ== X-Received: by 10.180.7.169 with SMTP id k9mr3176186wia.70.1430825111715; Tue, 05 May 2015 04:25:11 -0700 (PDT) Received: from [192.168.0.8] (97e3cdda.skybroadband.com. [151.227.205.218]) by mx.google.com with ESMTPSA id fa8sm15672953wib.14.2015.05.05.04.25.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 May 2015 04:25:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> Date: Tue, 5 May 2015 12:25:09 +0100 Message-Id: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> References: <21624.43602.459298.658726@mariner.uk.xensource.com> <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> To: Tim Mackey X-Mailer: Apple Mail (2.2098) Cc: George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7331225575796891851==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============7331225575796891851== Content-Type: multipart/alternative; boundary="Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14" --Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This came up again this time.=20 =46rom Wei: > FWIW I had an informal chat with the organiser and he told me this > format was indeed new to most Intel attendants. Another thins is that > the word hackathon was misleading because they were thinking about > coding and some (many?) engineers set up development environment = before > hand. So we should change the name * Xenvolution we can't use for trademark reasons * Xen Project Architecture Design and Deployment Summit is too long So I suggest we either go for "Xen Project Architect & Design Summit" or = "Xen Project Design Summit" If there are no objections, I will make a proposal to xen-devel@ and = other lists Regards Lars > On 2 Dec 2014, at 18:56, Tim Mackey wrote: >=20 > A thought to cover the various perspectives potential attendees have, = and crisply define why they should be there: > =20 > Xenvolution =E2=80=93 The Xen Project Architecture, Design and = Deployment Summit=20 > =20 > =20 > From: publicity-bounces@lists.xenproject.org = [mailto:publicity-bounces@lists.xenproject.org] On Behalf Of Sarah = Conway > Sent: Tuesday, December 02, 2014 1:44 PM > To: Konrad Rzeszutek Wilk > Cc: Lars Kurth; George Dunlap; publicity@lists.xenproject.org > Subject: Re: [Publicity] Another reason why our "hackathons" should be = called something else > =20 > Could always pair this catchy phrase with a longer, more formal title. = Use the short one-word title in some cases (social media); longer one = when necessary to communicate to different audiences or new audiences.=20= > =20 > Xenvolution: Architect, Design & Develop Meetup/Summit/Event=20 > =20 > Xenvolution - Annual (or Biannual) Xen Project Architect & Design = Summit=20 > =20 > Just a suggestion.=20 > =20 > =20 > =20 > On Tue, Dec 2, 2014 at 1:23 PM, Konrad Rzeszutek Wilk = > wrote: > On Tue, Dec 02, 2014 at 06:00:25PM +0000, Lars Kurth wrote: > > Some more ideas for names > > Design Summit > > Architecture & Design Summit >=20 > Xenvolution sounds pretty awesome :-) > > > > Lars > > > > On 2 Dec 2014, at 17:22, George Dunlap > wrote: > > > > > [Replies inline] > > > ________________________________________ > > > From: publicity-bounces@lists.xenproject.org = = [publicity-bounces@lists.xenproject.org = ] on behalf of Konrad = Rzeszutek Wilk [konrad.wilk@oracle.com ] > > > Sent: 02 December 2014 17:07 > > > To: Amir Chaudhry > > > Cc: Lars Kurth; publicity@lists.xenproject.org = > > > Subject: Re: [Publicity] Another reason why our "hackathons" = should be called something else > > > > > > On Tue, Dec 02, 2014 at 04:26:21PM +0000, Amir Chaudhry wrote: > > >> While calling them 'Meetings' might appeal to industrial partners = (a work-related, expensable visit?), it might turn off potential = attendees. > > >> > > >> Of course, you could just call the same event different things = for different audiences. > > > > > > Huddle Meeting? > > > Brainstorms? > > > > > > [George] Architecture storm? > > > Xenvolution? (Xen + evolution)? > > > > > > Really, "summit" is probably the best word, but "Xen Summit" = already means something else... > > > > > >=20 > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity = >=20 >=20 > =20 > --=20 > Sarah Conway > PR Manager > The Linux Foundation > sconway@linuxfoundation.org > (978) 578-5300 Cell > Skype: sarah.k.conway --Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This came up again this time. 

=46rom Wei:
> FWIW I had an informal = chat with the organiser and he told me this
> format was indeed new = to most Intel attendants. Another thins is that
> the word hackathon was = misleading because they were thinking about
> coding and some (many?) = engineers set up development environment before
> hand.

So we should change the name

* Xenvolution we can't use for = trademark reasons
* Xen Project Architecture Design = and Deployment Summit is too long

So I suggest we either go for "Xen = Project Architect & Design Summit" or "Xen Project Design = Summit"

If = there are no objections, I will make a proposal to xen-devel@ and other = lists

Regards
Lars

On = 2 Dec 2014, at 18:56, Tim Mackey <Timothy.Mackey@citrix.com> wrote:

A thought to cover the various = perspectives potential attendees have, and crisply define why they = should be there:
 
Xenvolution =E2=80=93 The Xen Project = Architecture, Design and Deployment Summit 
 
 
From: publicity-bounces@lists.xenproject.org [mailto:publicity-bounces@lists.xenproject.org] On Behalf = Of Sarah Conway
Sent: Tuesday, December 02, 2014 = 1:44 PM
To: Konrad Rzeszutek Wilk
Cc: Lars Kurth; George Dunlap; = publicity@lists.xenproject.org
Subject: Re: [Publicity] Another = reason why our "hackathons" should be called something else
 
Could always pair this catchy phrase with = a longer, more formal title. Use the short one-word title in some cases = (social media); longer one when necessary to communicate to different = audiences or new audiences. 
 
Xenvolution: Architect, Design & Develop = Meetup/Summit/Event 
 
Xenvolution - Annual (or Biannual) Xen Project = Architect & Design Summit 
 
Just a suggestion. 
 
 
 
On Tue, Dec 2, 2014 = at 1:23 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
On = Tue, Dec 02, 2014 at 06:00:25PM +0000, Lars Kurth wrote:
> Some more ideas for names
> Design = Summit
> Architecture & Design Summit

Xenvolution sounds pretty awesome :-)
>
> Lars
>
> On 2 Dec 2014, at 17:22, George = Dunlap <George.Dunlap@citrix.com> wrote:
>
> > [Replies inline]
> > = ________________________________________
> > = From: publicity-bounces@lists.xenproject.org [publicity-bounces@lists.xenproject.org] on behalf of = Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
> > Sent: 02 = December 2014 17:07
> > To: Amir Chaudhry
> > Cc: Lars Kurth; publicity@lists.xenproject.org
> > = Subject: Re: [Publicity] Another reason why our "hackathons" should be = called something else
> >
> > On = Tue, Dec 02, 2014 at 04:26:21PM +0000, Amir Chaudhry wrote:
> >> While calling them 'Meetings' might appeal to = industrial partners (a work-related, expensable visit?), it might turn = off potential attendees.
> >>
> = >> Of course, you could just call the same event different things = for different audiences.
> >
> > = Huddle Meeting?
> > Brainstorms?
> = >
> > [George] Architecture storm?
> > Xenvolution?  (Xen + evolution)?
> >
> > Really, "summit" is = probably the best word, but "Xen Summit" already means something = else...
> >
>

_______________________________________________
Publicity mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= /a>


-- 
Sarah Conway
The Linux = Foundation
sconway@linuxfoundation.org
(978) 578-5300  Cell
Skype: =  sarah.k.conway

= --Apple-Mail=_EF619DB3-3E3B-4A6D-B10A-58D2E333EC14-- --===============7331225575796891851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============7331225575796891851==-- From publicity-bounces@lists.xenproject.org Tue May 05 11:40:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 11:40:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbCk-0005r2-Ew; Tue, 05 May 2015 11:40:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbCi-0005qt-Sl for publicity@lists.xenproject.org; Tue, 05 May 2015 11:40:01 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id B8/DA-03202-01CA8455; Tue, 05 May 2015 11:40:00 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1430825998!8590071!1 X-Originating-IP: [209.85.212.174] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32701 invoked from network); 5 May 2015 11:39:58 -0000 Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 11:39:58 -0000 Received: by wiun10 with SMTP id n10so142584863wiu.1 for ; Tue, 05 May 2015 04:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=W7yc3aO6k9BIZLokkhYSLsIpjWIf1k1K9DkoXrQwux4=; b=j39LI4dazWwZ3yuVJ2h/FlO/usc/9yUFiwJv5uLE1qMC4OMbwMtGXqu7s0qcL/MWBn wbs8WZ0f5+nOCN467EPtt2L+kKQ6XuRhQZf0L00r7N32UgMtQHKX0ljdTy9mZjrqFCGh zT4b8gYvItUcjLVu/ptb/LkTjniTetmgESW8KOhYa7ydll1c2PaCm6OhV+quGTXaQOOc QxOOOgqoO52hw7T0DCVity4kZFway8B+TlDYbHTFj0yf5d7qfwKqOuHgRRLmP6H3xV/n 8a8zI4WCNLOvEFcsqb9vHYzd2KqB52QPh0+3Z842cJ1zlvs2kEU+DuePegoXvW2FDis4 Ye/Q== MIME-Version: 1.0 X-Received: by 10.194.172.72 with SMTP id ba8mr50666317wjc.136.1430825998040; Tue, 05 May 2015 04:39:58 -0700 (PDT) Received: by 10.194.163.194 with HTTP; Tue, 5 May 2015 04:39:57 -0700 (PDT) Received: by 10.194.163.194 with HTTP; Tue, 5 May 2015 04:39:57 -0700 (PDT) In-Reply-To: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> References: <21624.43602.459298.658726@mariner.uk.xensource.com> <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> Date: Tue, 5 May 2015 07:39:57 -0400 X-Google-Sender-Auth: vbJE8FdDqJn_QSY7rztQK-xlLRc Message-ID: From: Russ Pavlicek To: Lars Kurth Cc: George Dunlap , publicity@lists.xenproject.org Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6356179711822478108==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6356179711822478108== Content-Type: multipart/alternative; boundary=089e013c6b3459456c05155423b9 --089e013c6b3459456c05155423b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >"Xen Project Design Summit" +1 On May 5, 2015 7:25 AM, "Lars Kurth" wrote: > This came up again this time. > > From Wei: > > FWIW I had an informal chat with the organiser and he told me this > > format was indeed new to most Intel attendants. Another thins is that > > the word hackathon was misleading because they were thinking about > > coding and some (many?) engineers set up development environment before > > hand. > > So we should change the name > > * Xenvolution we can't use for trademark reasons > * Xen Project Architecture Design and Deployment Summit is too long > > So I suggest we either go for "Xen Project Architect & Design Summit" or > "Xen Project Design Summit" > > If there are no objections, I will make a proposal to xen-devel@ and > other lists > > Regards > Lars > > On 2 Dec 2014, at 18:56, Tim Mackey wrote: > > A thought to cover the various perspectives potential attendees have, and > crisply define why they should be there: > > Xenvolution =E2=80=93 The Xen Project Architecture, Design and Deployment= Summit > > > *From:* publicity-bounces@lists.xenproject.org [ > mailto:publicity-bounces@lists.xenproject.org > ] *On Behalf Of *Sarah Conway > *Sent:* Tuesday, December 02, 2014 1:44 PM > *To:* Konrad Rzeszutek Wilk > *Cc:* Lars Kurth; George Dunlap; publicity@lists.xenproject.org > *Subject:* Re: [Publicity] Another reason why our "hackathons" should be > called something else > > Could always pair this catchy phrase with a longer, more formal title. Us= e > the short one-word title in some cases (social media); longer one when > necessary to communicate to different audiences or new audiences. > > Xenvolution: Architect, Design & Develop Meetup/Summit/Event > > Xenvolution - Annual (or Biannual) Xen Project Architect & Design Summit > > Just a suggestion. > > > > On Tue, Dec 2, 2014 at 1:23 PM, Konrad Rzeszutek Wilk < > konrad.wilk@oracle.com> wrote: > On Tue, Dec 02, 2014 at 06:00:25PM +0000, Lars Kurth wrote: > > Some more ideas for names > > Design Summit > > Architecture & Design Summit > > Xenvolution sounds pretty awesome :-) > > > > Lars > > > > On 2 Dec 2014, at 17:22, George Dunlap wrote= : > > > > > [Replies inline] > > > ________________________________________ > > > From: publicity-bounces@lists.xenproject.org [ > publicity-bounces@lists.xenproject.org] on behalf of Konrad Rzeszutek > Wilk [konrad.wilk@oracle.com] > > > Sent: 02 December 2014 17:07 > > > To: Amir Chaudhry > > > Cc: Lars Kurth; publicity@lists.xenproject.org > > > Subject: Re: [Publicity] Another reason why our "hackathons" should b= e > called something else > > > > > > On Tue, Dec 02, 2014 at 04:26:21PM +0000, Amir Chaudhry wrote: > > >> While calling them 'Meetings' might appeal to industrial partners (a > work-related, expensable visit?), it might turn off potential attendees. > > >> > > >> Of course, you could just call the same event different things for > different audiences. > > > > > > Huddle Meeting? > > > Brainstorms? > > > > > > [George] Architecture storm? > > > Xenvolution? (Xen + evolution)? > > > > > > Really, "summit" is probably the best word, but "Xen Summit" already > means something else... > > > > > > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > > -- > Sarah Conway > PR Manager > The Linux Foundation > sconway@linuxfoundation.org > (978) 578-5300 Cell > Skype: sarah.k.conway > > > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > --089e013c6b3459456c05155423b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>"Xen Project Design Summit"
+1

On May 5, 2015 7:25 AM, "Lars Kurth" &= lt;lars.kurth.xen@gmail.com= > wrote:
This came up again this time.=C2=A0

From Wei:
> FWIW I= had an informal chat with the organiser and he told me this
> format was indeed new to most Intel attenda= nts. Another thins is that
> th= e word hackathon was misleading because they were thinking about
> coding and some (many?) engineers set u= p development environment before
&= gt; hand.

So = we should change the name

* Xenvolution we can't use= for trademark reasons
* Xen Project Architecture Design and Depl= oyment Summit is too long

So I suggest we either g= o for "Xen Project Architect & Design Summit" or "Xen Pr= oject Design Summit"

If there are no objectio= ns, I will make a proposal to xen-devel@ and other lists

Regards
Lars

=
On 2 Dec 2014, at 18:56, Tim Mackey <Timothy.Mackey@citrix.com> wrote:
A thought to cove= r the various perspectives potential attendees have, and crisply define why= they should be there:
=C2=A0
Xenvolution =E2=80=93 The Xe= n Project Architecture, Design and Deployment Summit=C2=A0
=C2=A0
=C2=A0
From:=C2=A0publicity-bounces@lists.xenproject.org [= mailto:publicity-bounces@lists.xenproject.org]=C2=A0On= Behalf Of=C2=A0Sarah Conway
Sent:=C2=A0Tuesday, December 02, 2014 1:44 PM
To:=C2=A0Kon= rad Rzeszutek Wilk
Cc:=C2=A0Lars Kurth; George Dunla= p; publ= icity@lists.xenproject.org
Subject:=C2=A0Re: [Pu= blicity] Another reason why our "hackathons" should be called som= ething else
= =C2=A0
Could always pair this catch= y phrase with a longer, more formal title. Use the short one-word title in = some cases (social media); longer one when necessary to communicate to diff= erent audiences or new audiences.=C2=A0
=C2=A0
Xe= nvolution: Architect, Design & Develop Meetup/Summit/Event=C2=A0=
=C2=A0
Xenvolution - Annual (or Biannual) Xen Proj= ect Architect & Design Summit=C2=A0
=C2=A0
Just a suggestion.=C2=A0
=C2=A0
= =C2=A0
=C2=A0=
On Tue, Dec 2, 2014 at 1:23 PM, Konra= d Rzeszutek Wilk <konrad.wilk@oracle.c= om> wrote:
On Tue, Dec 02,= 2014 at 06:00:25PM +0000, Lars Kurth wrote:
> Some more ideas for na= mes
> Design Summit
> Architecture & Design Summit

X= envolution sounds pretty awesome :-)
>
> Lars
>
> On 2 Dec 2014, at 17:22, Ge= orge Dunlap <George.Dunlap@citrix.co= m> wrote:
>
> > [Replies inline]
> > _______= _________________________________
> > From:=C2=A0publicity-bounces@lists.xenpr= oject.org=C2=A0[publicity-bounces@lists.xenproject.org] on behalf of Konrad Rze= szutek Wilk [konrad.wilk@oracle.com]<= br>> > Sent: 02 December 2014 17:07
> > To: Amir Chaudhry> > Cc: Lars Kurth;=C2=A0publicity@lists.xenproject.org
> > Subject: Re: [P= ublicity] Another reason why our "hackathons" should be called so= mething else
> >
> > On Tue, Dec 02, 2014 at 04:26:21PM += 0000, Amir Chaudhry wrote:
> >> While calling them 'Meeting= s' might appeal to industrial partners (a work-related, expensable visi= t?), it might turn off potential attendees.
> >>
> >&g= t; Of course, you could just call the same event different things for diffe= rent audiences.
> >
> > Huddle Meeting?
> > Brai= nstorms?
> >
> > [George] Architecture storm?
> >= ; Xenvolution?=C2=A0 (Xen + evolution)?
> >
> > Really, &= quot;summit" is probably the best word, but "Xen Summit" alr= eady means something else...
> >
>

__________________= _____________________________
Publicity mailing list
Publicity@lists.xenproject.org
http://lists.xenpro= ject.org/cgi-bin/mailman/listinfo/publicity


=
=C2=A0
--=C2=A0
Sarah Conway
PR Manager
The Lin= ux Foundation
sconway@linuxfounda= tion.org
(978= ) 578-5300 =C2=A0Cell
Skype: =C2=A0sarah.k.conway


________________________________= _______________
Publicity mailing list
Publicity@lists.xenprojec= t.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publ= icity

--089e013c6b3459456c05155423b9-- --===============6356179711822478108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6356179711822478108==-- From publicity-bounces@lists.xenproject.org Tue May 05 11:40:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 11:40:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbCk-0005r2-Ew; Tue, 05 May 2015 11:40:02 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbCi-0005qt-Sl for publicity@lists.xenproject.org; Tue, 05 May 2015 11:40:01 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id B8/DA-03202-01CA8455; Tue, 05 May 2015 11:40:00 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1430825998!8590071!1 X-Originating-IP: [209.85.212.174] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32701 invoked from network); 5 May 2015 11:39:58 -0000 Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 11:39:58 -0000 Received: by wiun10 with SMTP id n10so142584863wiu.1 for ; Tue, 05 May 2015 04:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=W7yc3aO6k9BIZLokkhYSLsIpjWIf1k1K9DkoXrQwux4=; b=j39LI4dazWwZ3yuVJ2h/FlO/usc/9yUFiwJv5uLE1qMC4OMbwMtGXqu7s0qcL/MWBn wbs8WZ0f5+nOCN467EPtt2L+kKQ6XuRhQZf0L00r7N32UgMtQHKX0ljdTy9mZjrqFCGh zT4b8gYvItUcjLVu/ptb/LkTjniTetmgESW8KOhYa7ydll1c2PaCm6OhV+quGTXaQOOc QxOOOgqoO52hw7T0DCVity4kZFway8B+TlDYbHTFj0yf5d7qfwKqOuHgRRLmP6H3xV/n 8a8zI4WCNLOvEFcsqb9vHYzd2KqB52QPh0+3Z842cJ1zlvs2kEU+DuePegoXvW2FDis4 Ye/Q== MIME-Version: 1.0 X-Received: by 10.194.172.72 with SMTP id ba8mr50666317wjc.136.1430825998040; Tue, 05 May 2015 04:39:58 -0700 (PDT) Received: by 10.194.163.194 with HTTP; Tue, 5 May 2015 04:39:57 -0700 (PDT) Received: by 10.194.163.194 with HTTP; Tue, 5 May 2015 04:39:57 -0700 (PDT) In-Reply-To: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> References: <21624.43602.459298.658726@mariner.uk.xensource.com> <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> Date: Tue, 5 May 2015 07:39:57 -0400 X-Google-Sender-Auth: vbJE8FdDqJn_QSY7rztQK-xlLRc Message-ID: From: Russ Pavlicek To: Lars Kurth Cc: George Dunlap , publicity@lists.xenproject.org Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6356179711822478108==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6356179711822478108== Content-Type: multipart/alternative; boundary=089e013c6b3459456c05155423b9 --089e013c6b3459456c05155423b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >"Xen Project Design Summit" +1 On May 5, 2015 7:25 AM, "Lars Kurth" wrote: > This came up again this time. > > From Wei: > > FWIW I had an informal chat with the organiser and he told me this > > format was indeed new to most Intel attendants. Another thins is that > > the word hackathon was misleading because they were thinking about > > coding and some (many?) engineers set up development environment before > > hand. > > So we should change the name > > * Xenvolution we can't use for trademark reasons > * Xen Project Architecture Design and Deployment Summit is too long > > So I suggest we either go for "Xen Project Architect & Design Summit" or > "Xen Project Design Summit" > > If there are no objections, I will make a proposal to xen-devel@ and > other lists > > Regards > Lars > > On 2 Dec 2014, at 18:56, Tim Mackey wrote: > > A thought to cover the various perspectives potential attendees have, and > crisply define why they should be there: > > Xenvolution =E2=80=93 The Xen Project Architecture, Design and Deployment= Summit > > > *From:* publicity-bounces@lists.xenproject.org [ > mailto:publicity-bounces@lists.xenproject.org > ] *On Behalf Of *Sarah Conway > *Sent:* Tuesday, December 02, 2014 1:44 PM > *To:* Konrad Rzeszutek Wilk > *Cc:* Lars Kurth; George Dunlap; publicity@lists.xenproject.org > *Subject:* Re: [Publicity] Another reason why our "hackathons" should be > called something else > > Could always pair this catchy phrase with a longer, more formal title. Us= e > the short one-word title in some cases (social media); longer one when > necessary to communicate to different audiences or new audiences. > > Xenvolution: Architect, Design & Develop Meetup/Summit/Event > > Xenvolution - Annual (or Biannual) Xen Project Architect & Design Summit > > Just a suggestion. > > > > On Tue, Dec 2, 2014 at 1:23 PM, Konrad Rzeszutek Wilk < > konrad.wilk@oracle.com> wrote: > On Tue, Dec 02, 2014 at 06:00:25PM +0000, Lars Kurth wrote: > > Some more ideas for names > > Design Summit > > Architecture & Design Summit > > Xenvolution sounds pretty awesome :-) > > > > Lars > > > > On 2 Dec 2014, at 17:22, George Dunlap wrote= : > > > > > [Replies inline] > > > ________________________________________ > > > From: publicity-bounces@lists.xenproject.org [ > publicity-bounces@lists.xenproject.org] on behalf of Konrad Rzeszutek > Wilk [konrad.wilk@oracle.com] > > > Sent: 02 December 2014 17:07 > > > To: Amir Chaudhry > > > Cc: Lars Kurth; publicity@lists.xenproject.org > > > Subject: Re: [Publicity] Another reason why our "hackathons" should b= e > called something else > > > > > > On Tue, Dec 02, 2014 at 04:26:21PM +0000, Amir Chaudhry wrote: > > >> While calling them 'Meetings' might appeal to industrial partners (a > work-related, expensable visit?), it might turn off potential attendees. > > >> > > >> Of course, you could just call the same event different things for > different audiences. > > > > > > Huddle Meeting? > > > Brainstorms? > > > > > > [George] Architecture storm? > > > Xenvolution? (Xen + evolution)? > > > > > > Really, "summit" is probably the best word, but "Xen Summit" already > means something else... > > > > > > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > > -- > Sarah Conway > PR Manager > The Linux Foundation > sconway@linuxfoundation.org > (978) 578-5300 Cell > Skype: sarah.k.conway > > > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > --089e013c6b3459456c05155423b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>"Xen Project Design Summit"
+1

On May 5, 2015 7:25 AM, "Lars Kurth" &= lt;lars.kurth.xen@gmail.com= > wrote:
This came up again this time.=C2=A0

From Wei:
> FWIW I= had an informal chat with the organiser and he told me this
> format was indeed new to most Intel attenda= nts. Another thins is that
> th= e word hackathon was misleading because they were thinking about
> coding and some (many?) engineers set u= p development environment before
&= gt; hand.

So = we should change the name

* Xenvolution we can't use= for trademark reasons
* Xen Project Architecture Design and Depl= oyment Summit is too long

So I suggest we either g= o for "Xen Project Architect & Design Summit" or "Xen Pr= oject Design Summit"

If there are no objectio= ns, I will make a proposal to xen-devel@ and other lists

Regards
Lars

=
On 2 Dec 2014, at 18:56, Tim Mackey <Timothy.Mackey@citrix.com> wrote:
A thought to cove= r the various perspectives potential attendees have, and crisply define why= they should be there:
=C2=A0
Xenvolution =E2=80=93 The Xe= n Project Architecture, Design and Deployment Summit=C2=A0
=C2=A0
=C2=A0
From:=C2=A0publicity-bounces@lists.xenproject.org [= mailto:publicity-bounces@lists.xenproject.org]=C2=A0On= Behalf Of=C2=A0Sarah Conway
Sent:=C2=A0Tuesday, December 02, 2014 1:44 PM
To:=C2=A0Kon= rad Rzeszutek Wilk
Cc:=C2=A0Lars Kurth; George Dunla= p; publ= icity@lists.xenproject.org
Subject:=C2=A0Re: [Pu= blicity] Another reason why our "hackathons" should be called som= ething else
= =C2=A0
Could always pair this catch= y phrase with a longer, more formal title. Use the short one-word title in = some cases (social media); longer one when necessary to communicate to diff= erent audiences or new audiences.=C2=A0
=C2=A0
Xe= nvolution: Architect, Design & Develop Meetup/Summit/Event=C2=A0=
=C2=A0
Xenvolution - Annual (or Biannual) Xen Proj= ect Architect & Design Summit=C2=A0
=C2=A0
Just a suggestion.=C2=A0
=C2=A0
= =C2=A0
=C2=A0=
On Tue, Dec 2, 2014 at 1:23 PM, Konra= d Rzeszutek Wilk <konrad.wilk@oracle.c= om> wrote:
On Tue, Dec 02,= 2014 at 06:00:25PM +0000, Lars Kurth wrote:
> Some more ideas for na= mes
> Design Summit
> Architecture & Design Summit

X= envolution sounds pretty awesome :-)
>
> Lars
>
> On 2 Dec 2014, at 17:22, Ge= orge Dunlap <George.Dunlap@citrix.co= m> wrote:
>
> > [Replies inline]
> > _______= _________________________________
> > From:=C2=A0publicity-bounces@lists.xenpr= oject.org=C2=A0[publicity-bounces@lists.xenproject.org] on behalf of Konrad Rze= szutek Wilk [konrad.wilk@oracle.com]<= br>> > Sent: 02 December 2014 17:07
> > To: Amir Chaudhry> > Cc: Lars Kurth;=C2=A0publicity@lists.xenproject.org
> > Subject: Re: [P= ublicity] Another reason why our "hackathons" should be called so= mething else
> >
> > On Tue, Dec 02, 2014 at 04:26:21PM += 0000, Amir Chaudhry wrote:
> >> While calling them 'Meeting= s' might appeal to industrial partners (a work-related, expensable visi= t?), it might turn off potential attendees.
> >>
> >&g= t; Of course, you could just call the same event different things for diffe= rent audiences.
> >
> > Huddle Meeting?
> > Brai= nstorms?
> >
> > [George] Architecture storm?
> >= ; Xenvolution?=C2=A0 (Xen + evolution)?
> >
> > Really, &= quot;summit" is probably the best word, but "Xen Summit" alr= eady means something else...
> >
>

__________________= _____________________________
Publicity mailing list
Publicity@lists.xenproject.org
http://lists.xenpro= ject.org/cgi-bin/mailman/listinfo/publicity


=
=C2=A0
--=C2=A0
Sarah Conway
PR Manager
The Lin= ux Foundation
sconway@linuxfounda= tion.org
(978= ) 578-5300 =C2=A0Cell
Skype: =C2=A0sarah.k.conway


________________________________= _______________
Publicity mailing list
Publicity@lists.xenprojec= t.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publ= icity

--089e013c6b3459456c05155423b9-- --===============6356179711822478108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6356179711822478108==-- From publicity-bounces@lists.xenproject.org Tue May 05 11:46:21 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 11:46:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbIr-0006QP-B4; Tue, 05 May 2015 11:46:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbIp-0006Pq-Pk for publicity@lists.xenproject.org; Tue, 05 May 2015 11:46:19 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 46/35-12069-A8DA8455; Tue, 05 May 2015 11:46:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1430826376!12409537!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7677 invoked from network); 5 May 2015 11:46:18 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 11:46:18 -0000 X-IronPort-AV: E=Sophos;i="5.13,372,1427760000"; d="scan'208";a="261742675" Message-ID: <1430826374.2660.55.camel@citrix.com> From: Ian Campbell To: Lars Kurth Date: Tue, 5 May 2015 12:46:14 +0100 In-Reply-To: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> References: <21624.43602.459298.658726@mariner.uk.xensource.com> <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Tue, 2015-05-05 at 12:25 +0100, Lars Kurth wrote: > So I suggest we either go for "Xen Project Architect & Design Summit" Should be "X P Architecture & D S", but... > or "Xen Project Design Summit" ... I prefer this one anyway. Ian. _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 11:46:21 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 11:46:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbIr-0006QP-B4; Tue, 05 May 2015 11:46:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpbIp-0006Pq-Pk for publicity@lists.xenproject.org; Tue, 05 May 2015 11:46:19 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 46/35-12069-A8DA8455; Tue, 05 May 2015 11:46:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1430826376!12409537!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7677 invoked from network); 5 May 2015 11:46:18 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 11:46:18 -0000 X-IronPort-AV: E=Sophos;i="5.13,372,1427760000"; d="scan'208";a="261742675" Message-ID: <1430826374.2660.55.camel@citrix.com> From: Ian Campbell To: Lars Kurth Date: Tue, 5 May 2015 12:46:14 +0100 In-Reply-To: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> References: <21624.43602.459298.658726@mariner.uk.xensource.com> <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Tue, 2015-05-05 at 12:25 +0100, Lars Kurth wrote: > So I suggest we either go for "Xen Project Architect & Design Summit" Should be "X P Architecture & D S", but... > or "Xen Project Design Summit" ... I prefer this one anyway. Ian. _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 13:28:45 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 13:28:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ypctx-0006k6-3j; Tue, 05 May 2015 13:28:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ypctw-0006k1-Lp for publicity@lists.xenproject.org; Tue, 05 May 2015 13:28:44 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id B7/A7-07318-B85C8455; Tue, 05 May 2015 13:28:43 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1430832521!12429520!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26321 invoked from network); 5 May 2015 13:28:43 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2015 13:28:43 -0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t45DSdfO010151 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 May 2015 13:28:40 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t45DSdPg023380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2015 13:28:39 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t45DSdsq007457; Tue, 5 May 2015 13:28:39 GMT Received: from l.oracle.com (/10.137.178.253) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 May 2015 06:28:38 -0700 Received: by l.oracle.com (Postfix, from userid 1000) id DA39A6A472F; Tue, 5 May 2015 09:28:37 -0400 (EDT) Date: Tue, 5 May 2015 09:28:37 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20150505132837.GE25509@l.oracle.com> References: <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> <1430826374.2660.55.camel@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1430826374.2660.55.camel@citrix.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Source-IP: userv0021.oracle.com [156.151.31.71] Cc: Lars Kurth , George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Tue, May 05, 2015 at 12:46:14PM +0100, Ian Campbell wrote: > On Tue, 2015-05-05 at 12:25 +0100, Lars Kurth wrote: > > So I suggest we either go for "Xen Project Architect & Design Summit" > > Should be "X P Architecture & D S", but... > > > or "Xen Project Design Summit" > > ... I prefer this one anyway. +1 > > Ian. > > > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 13:28:45 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 13:28:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ypctx-0006k6-3j; Tue, 05 May 2015 13:28:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ypctw-0006k1-Lp for publicity@lists.xenproject.org; Tue, 05 May 2015 13:28:44 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id B7/A7-07318-B85C8455; Tue, 05 May 2015 13:28:43 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1430832521!12429520!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26321 invoked from network); 5 May 2015 13:28:43 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-10.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2015 13:28:43 -0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t45DSdfO010151 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 May 2015 13:28:40 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t45DSdPg023380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2015 13:28:39 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t45DSdsq007457; Tue, 5 May 2015 13:28:39 GMT Received: from l.oracle.com (/10.137.178.253) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 May 2015 06:28:38 -0700 Received: by l.oracle.com (Postfix, from userid 1000) id DA39A6A472F; Tue, 5 May 2015 09:28:37 -0400 (EDT) Date: Tue, 5 May 2015 09:28:37 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20150505132837.GE25509@l.oracle.com> References: <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> <1430826374.2660.55.camel@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1430826374.2660.55.camel@citrix.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Source-IP: userv0021.oracle.com [156.151.31.71] Cc: Lars Kurth , George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Tue, May 05, 2015 at 12:46:14PM +0100, Ian Campbell wrote: > On Tue, 2015-05-05 at 12:25 +0100, Lars Kurth wrote: > > So I suggest we either go for "Xen Project Architect & Design Summit" > > Should be "X P Architecture & D S", but... > > > or "Xen Project Design Summit" > > ... I prefer this one anyway. +1 > > Ian. > > > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 14:28:09 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 14:28:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpdpR-0003UN-1U; Tue, 05 May 2015 14:28:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpdpP-0003Tv-Dm for publicity@lists.xenproject.org; Tue, 05 May 2015 14:28:07 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 2D/63-23555-673D8455; Tue, 05 May 2015 14:28:06 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1430836084!12522379!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1200 invoked from network); 5 May 2015 14:28:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 14:28:05 -0000 X-IronPort-AV: E=Sophos;i="5.13,372,1427760000"; d="scan'208";a="261816532" Date: Tue, 5 May 2015 15:10:43 +0100 From: Wei Liu To: Lars Kurth Message-ID: <20150505141043.GG1455@zion.uk.xensource.com> References: <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-DLP: MIA2 Cc: George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Tue, May 05, 2015 at 12:25:09PM +0100, Lars Kurth wrote: > This came up again this time. > > From Wei: > > FWIW I had an informal chat with the organiser and he told me this > > format was indeed new to most Intel attendants. Another thins is that > > the word hackathon was misleading because they were thinking about > > coding and some (many?) engineers set up development environment before > > hand. > > So we should change the name > > * Xenvolution we can't use for trademark reasons > * Xen Project Architecture Design and Deployment Summit is too long > > So I suggest we either go for "Xen Project Architect & Design Summit" or "Xen Project Design Summit" > +1 for Xen Project Design Summit _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 14:28:09 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 14:28:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpdpR-0003UN-1U; Tue, 05 May 2015 14:28:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YpdpP-0003Tv-Dm for publicity@lists.xenproject.org; Tue, 05 May 2015 14:28:07 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 2D/63-23555-673D8455; Tue, 05 May 2015 14:28:06 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1430836084!12522379!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1200 invoked from network); 5 May 2015 14:28:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 14:28:05 -0000 X-IronPort-AV: E=Sophos;i="5.13,372,1427760000"; d="scan'208";a="261816532" Date: Tue, 5 May 2015 15:10:43 +0100 From: Wei Liu To: Lars Kurth Message-ID: <20150505141043.GG1455@zion.uk.xensource.com> References: <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-DLP: MIA2 Cc: George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Tue, May 05, 2015 at 12:25:09PM +0100, Lars Kurth wrote: > This came up again this time. > > From Wei: > > FWIW I had an informal chat with the organiser and he told me this > > format was indeed new to most Intel attendants. Another thins is that > > the word hackathon was misleading because they were thinking about > > coding and some (many?) engineers set up development environment before > > hand. > > So we should change the name > > * Xenvolution we can't use for trademark reasons > * Xen Project Architecture Design and Deployment Summit is too long > > So I suggest we either go for "Xen Project Architect & Design Summit" or "Xen Project Design Summit" > +1 for Xen Project Design Summit _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 14:47:12 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 14:47:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype7s-0005vH-EN; Tue, 05 May 2015 14:47:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype7q-0005us-Jv for publicity@lists.xenproject.org; Tue, 05 May 2015 14:47:10 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id A3/24-03032-DE7D8455; Tue, 05 May 2015 14:47:09 +0000 X-Env-Sender: Mark.Hinkle@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1430837227!14805579!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3864 invoked from network); 5 May 2015 14:47:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 14:47:08 -0000 X-IronPort-AV: E=Sophos;i="5.13,373,1427760000"; d="scan'208";a="261827961" From: Mark Hinkle To: Wei Liu Thread-Topic: [Publicity] Another reason why our "hackathons" should be called something else Thread-Index: AQHQh0CpgWx7BXqev0mtPfhEnsoRPZ1tuEEA Date: Tue, 5 May 2015 14:43:32 +0000 Message-ID: References: <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> <20150505141043.GG1455@zion.uk.xensource.com> In-Reply-To: <20150505141043.GG1455@zion.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <26604775A8C92C4BBF6BC5C890D815D3@citrix.com> MIME-Version: 1.0 X-DLP: MIA2 Cc: Lars Kurth , George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org +1 for Xen Project Design Summit Mark > On May 5, 2015, at 10:10 AM, Wei Liu wrote: > > On Tue, May 05, 2015 at 12:25:09PM +0100, Lars Kurth wrote: >> This came up again this time. >> >> From Wei: >>> FWIW I had an informal chat with the organiser and he told me this >>> format was indeed new to most Intel attendants. Another thins is that >>> the word hackathon was misleading because they were thinking about >>> coding and some (many?) engineers set up development environment before >>> hand. >> >> So we should change the name >> >> * Xenvolution we can't use for trademark reasons >> * Xen Project Architecture Design and Deployment Summit is too long >> >> So I suggest we either go for "Xen Project Architect & Design Summit" or "Xen Project Design Summit" >> > > +1 for Xen Project Design Summit > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 14:47:12 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 14:47:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype7s-0005vH-EN; Tue, 05 May 2015 14:47:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype7q-0005us-Jv for publicity@lists.xenproject.org; Tue, 05 May 2015 14:47:10 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id A3/24-03032-DE7D8455; Tue, 05 May 2015 14:47:09 +0000 X-Env-Sender: Mark.Hinkle@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1430837227!14805579!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3864 invoked from network); 5 May 2015 14:47:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 14:47:08 -0000 X-IronPort-AV: E=Sophos;i="5.13,373,1427760000"; d="scan'208";a="261827961" From: Mark Hinkle To: Wei Liu Thread-Topic: [Publicity] Another reason why our "hackathons" should be called something else Thread-Index: AQHQh0CpgWx7BXqev0mtPfhEnsoRPZ1tuEEA Date: Tue, 5 May 2015 14:43:32 +0000 Message-ID: References: <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> <20150505141043.GG1455@zion.uk.xensource.com> In-Reply-To: <20150505141043.GG1455@zion.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <26604775A8C92C4BBF6BC5C890D815D3@citrix.com> MIME-Version: 1.0 X-DLP: MIA2 Cc: Lars Kurth , George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org +1 for Xen Project Design Summit Mark > On May 5, 2015, at 10:10 AM, Wei Liu wrote: > > On Tue, May 05, 2015 at 12:25:09PM +0100, Lars Kurth wrote: >> This came up again this time. >> >> From Wei: >>> FWIW I had an informal chat with the organiser and he told me this >>> format was indeed new to most Intel attendants. Another thins is that >>> the word hackathon was misleading because they were thinking about >>> coding and some (many?) engineers set up development environment before >>> hand. >> >> So we should change the name >> >> * Xenvolution we can't use for trademark reasons >> * Xen Project Architecture Design and Deployment Summit is too long >> >> So I suggest we either go for "Xen Project Architect & Design Summit" or "Xen Project Design Summit" >> > > +1 for Xen Project Design Summit > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 14:47:30 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 14:47:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype8A-0005y2-GT; Tue, 05 May 2015 14:47:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype8A-0005xp-0l for publicity@lists.xenproject.org; Tue, 05 May 2015 14:47:30 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id E7/31-02789-108D8455; Tue, 05 May 2015 14:47:29 +0000 X-Env-Sender: Mark.Hinkle@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1430837246!12739161!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5991 invoked from network); 5 May 2015 14:47:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 14:47:28 -0000 X-IronPort-AV: E=Sophos;i="5.13,373,1427760000"; d="scan'208";a="259576058" From: Mark Hinkle To: Wei Liu Thread-Topic: [Publicity] Another reason why our "hackathons" should be called something else Thread-Index: AQHQh0CpgWx7BXqev0mtPfhEnsoRPZ1tuEEA Date: Tue, 5 May 2015 14:43:31 +0000 Message-ID: <6754B1E6-F7CF-43B8-A0F7-2980E9D99267@citrix.com> References: <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> <20150505141043.GG1455@zion.uk.xensource.com> In-Reply-To: <20150505141043.GG1455@zion.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <8F235E58000A924380103CDCC6E31CFD@citrix.com> MIME-Version: 1.0 X-DLP: MIA1 Cc: Lars Kurth , George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org +1 for Xen Project Design Summit Mark > On May 5, 2015, at 10:10 AM, Wei Liu wrote: > > On Tue, May 05, 2015 at 12:25:09PM +0100, Lars Kurth wrote: >> This came up again this time. >> >> From Wei: >>> FWIW I had an informal chat with the organiser and he told me this >>> format was indeed new to most Intel attendants. Another thins is that >>> the word hackathon was misleading because they were thinking about >>> coding and some (many?) engineers set up development environment before >>> hand. >> >> So we should change the name >> >> * Xenvolution we can't use for trademark reasons >> * Xen Project Architecture Design and Deployment Summit is too long >> >> So I suggest we either go for "Xen Project Architect & Design Summit" or "Xen Project Design Summit" >> > > +1 for Xen Project Design Summit > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Tue May 05 14:47:30 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2015 14:47:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype8A-0005y2-GT; Tue, 05 May 2015 14:47:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ype8A-0005xp-0l for publicity@lists.xenproject.org; Tue, 05 May 2015 14:47:30 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id E7/31-02789-108D8455; Tue, 05 May 2015 14:47:29 +0000 X-Env-Sender: Mark.Hinkle@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1430837246!12739161!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5991 invoked from network); 5 May 2015 14:47:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 May 2015 14:47:28 -0000 X-IronPort-AV: E=Sophos;i="5.13,373,1427760000"; d="scan'208";a="259576058" From: Mark Hinkle To: Wei Liu Thread-Topic: [Publicity] Another reason why our "hackathons" should be called something else Thread-Index: AQHQh0CpgWx7BXqev0mtPfhEnsoRPZ1tuEEA Date: Tue, 5 May 2015 14:43:31 +0000 Message-ID: <6754B1E6-F7CF-43B8-A0F7-2980E9D99267@citrix.com> References: <7908E776-3AA9-48EE-A595-C12F79C684EB@cam.ac.uk> <8D8BC1EB-7A17-4AB5-8BC6-661B5FEDA1F1@cam.ac.uk> <20141202170712.GD31436@laptop.dumpdata.com> <29644B96F4F939498A77B25AA8831B0D253B9F00@AMSPEX01CL01.citrite.net> <99561EB9-A05D-4089-BB4B-2D42D40CA347@gmail.com> <20141202182345.GC32385@laptop.dumpdata.com> <3AE67AE02427BC45A5A40EF6762308D4069D4669@FTLPEX01CL02.citrite.net> <3BDA445A-DAF2-47E1-9C64-03CA58BA0887@gmail.com> <20150505141043.GG1455@zion.uk.xensource.com> In-Reply-To: <20150505141043.GG1455@zion.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-ID: <8F235E58000A924380103CDCC6E31CFD@citrix.com> MIME-Version: 1.0 X-DLP: MIA1 Cc: Lars Kurth , George Dunlap , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Another reason why our "hackathons" should be called something else X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org +1 for Xen Project Design Summit Mark > On May 5, 2015, at 10:10 AM, Wei Liu wrote: > > On Tue, May 05, 2015 at 12:25:09PM +0100, Lars Kurth wrote: >> This came up again this time. >> >> From Wei: >>> FWIW I had an informal chat with the organiser and he told me this >>> format was indeed new to most Intel attendants. Another thins is that >>> the word hackathon was misleading because they were thinking about >>> coding and some (many?) engineers set up development environment before >>> hand. >> >> So we should change the name >> >> * Xenvolution we can't use for trademark reasons >> * Xen Project Architecture Design and Deployment Summit is too long >> >> So I suggest we either go for "Xen Project Architect & Design Summit" or "Xen Project Design Summit" >> > > +1 for Xen Project Design Summit > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Wed May 06 16:16:26 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 06 May 2015 16:16:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yq1zl-00038Y-6n; Wed, 06 May 2015 16:16:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yq1zj-00038N-0W for publicity@lists.xenproject.org; Wed, 06 May 2015 16:16:23 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 19/62-02788-65E3A455; Wed, 06 May 2015 16:16:22 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1430928980!15202883!1 X-Originating-IP: [209.85.160.169] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18964 invoked from network); 6 May 2015 16:16:21 -0000 Received: from mail-yk0-f169.google.com (HELO mail-yk0-f169.google.com) (209.85.160.169) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2015 16:16:21 -0000 Received: by ykeo186 with SMTP id o186so3847348yke.0 for ; Wed, 06 May 2015 09:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=iZ70bDrTfFGR7rnnQY/t5UTLkntO00j8Hf5p/2wuQYs=; b=sb+azOpLYV8/sX/iD1P1oMfdWL/R9rl2a6sbxY6H+fTAWPYzpA4V97gn1LKaKOaZlO otnwZ5IqvwslsvNq/FhBcJ80YpFBrDBc5Gnny+VTjQ/fiKK7dKQUl8LzxOdjS+xn4kOy r3zSJeANIaFfEh6xKmunRLNG9RIC0dvwaPlp+S3XnGIFQxh2/G8EnfpFheCMyKAlzFfB Y7ni7tZncfvQDrY2QUHbbkxXDHWt1BPAEyzYekQU4ZVW9DRhnFCDgV2aAX/9rj2CsqTN at+gvL13Ou9X0CUXE93bxoS0x3qoimVFvsVQJism9umsTd9iRBi9iLIbcnrdgEqyr3pE w58w== X-Received: by 10.236.32.136 with SMTP id o8mr6208871yha.162.1430928979899; Wed, 06 May 2015 09:16:19 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id 41sm278747yhp.33.2015.05.06.09.16.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 May 2015 09:16:19 -0700 (PDT) From: Lars Kurth Message-Id: <18E84B92-78AA-44EA-9640-D49E55BD9A73@gmail.com> Date: Wed, 6 May 2015 17:16:16 +0100 To: publicity@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Publicity] Hackathon Event Report Blog Post available for review X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3456103023622753363==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============3456103023622753363== Content-Type: multipart/alternative; boundary="Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99" --Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://blog.xenproject.org/?p=3D10655&preview=3Dtrue = Would like to publish tomorrow Lars= --Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii https://blog.xenproject.org/?p=10655&preview=true
Would like to publish tomorrow
Lars
--Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99-- --===============3456103023622753363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============3456103023622753363==-- From publicity-bounces@lists.xenproject.org Wed May 06 16:16:26 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 06 May 2015 16:16:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yq1zl-00038Y-6n; Wed, 06 May 2015 16:16:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yq1zj-00038N-0W for publicity@lists.xenproject.org; Wed, 06 May 2015 16:16:23 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 19/62-02788-65E3A455; Wed, 06 May 2015 16:16:22 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1430928980!15202883!1 X-Originating-IP: [209.85.160.169] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18964 invoked from network); 6 May 2015 16:16:21 -0000 Received: from mail-yk0-f169.google.com (HELO mail-yk0-f169.google.com) (209.85.160.169) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 May 2015 16:16:21 -0000 Received: by ykeo186 with SMTP id o186so3847348yke.0 for ; Wed, 06 May 2015 09:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=iZ70bDrTfFGR7rnnQY/t5UTLkntO00j8Hf5p/2wuQYs=; b=sb+azOpLYV8/sX/iD1P1oMfdWL/R9rl2a6sbxY6H+fTAWPYzpA4V97gn1LKaKOaZlO otnwZ5IqvwslsvNq/FhBcJ80YpFBrDBc5Gnny+VTjQ/fiKK7dKQUl8LzxOdjS+xn4kOy r3zSJeANIaFfEh6xKmunRLNG9RIC0dvwaPlp+S3XnGIFQxh2/G8EnfpFheCMyKAlzFfB Y7ni7tZncfvQDrY2QUHbbkxXDHWt1BPAEyzYekQU4ZVW9DRhnFCDgV2aAX/9rj2CsqTN at+gvL13Ou9X0CUXE93bxoS0x3qoimVFvsVQJism9umsTd9iRBi9iLIbcnrdgEqyr3pE w58w== X-Received: by 10.236.32.136 with SMTP id o8mr6208871yha.162.1430928979899; Wed, 06 May 2015 09:16:19 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id 41sm278747yhp.33.2015.05.06.09.16.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 May 2015 09:16:19 -0700 (PDT) From: Lars Kurth Message-Id: <18E84B92-78AA-44EA-9640-D49E55BD9A73@gmail.com> Date: Wed, 6 May 2015 17:16:16 +0100 To: publicity@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Publicity] Hackathon Event Report Blog Post available for review X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3456103023622753363==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============3456103023622753363== Content-Type: multipart/alternative; boundary="Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99" --Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://blog.xenproject.org/?p=3D10655&preview=3Dtrue = Would like to publish tomorrow Lars= --Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii https://blog.xenproject.org/?p=10655&preview=true
Would like to publish tomorrow
Lars
--Apple-Mail=_2409CC9D-9996-4197-9733-60D583413C99-- --===============3456103023622753363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============3456103023622753363==-- From publicity-bounces@lists.xenproject.org Wed May 13 09:59:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 May 2015 09:59:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsTRO-00013U-3p; Wed, 13 May 2015 09:59:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsFFt-00030i-2h for publicity@lists.xenproject.org; Tue, 12 May 2015 18:50:13 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 2E/24-03561-46B42555; Tue, 12 May 2015 18:50:12 +0000 X-Env-Sender: zack@zackwhittaker.co.uk X-Msg-Ref: server-12.tower-206.messagelabs.com!1431456609!14475457!1 X-Originating-IP: [108.166.43.126] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8706 invoked from network); 12 May 2015 18:50:09 -0000 Received: from smtp126.ord1c.emailsrvr.com (HELO smtp126.ord1c.emailsrvr.com) (108.166.43.126) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2015 18:50:09 -0000 Received: from smtp16.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C75BF180382 for ; Tue, 12 May 2015 14:50:08 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp16.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B9D5B1801C0 for ; Tue, 12 May 2015 14:50:08 -0400 (EDT) Received: from smtp192.mex05.mlsrvr.com (unknown [184.106.31.85]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTPS id A50BC180402 for ; Tue, 12 May 2015 14:50:08 -0400 (EDT) X-Sender-Id: zack@zackwhittaker.co.uk Received: from smtp192.mex05.mlsrvr.com ([UNAVAILABLE]. [184.106.31.85]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:25 (trex/5.4.2); Tue, 12 May 2015 18:50:08 GMT Received: from ORD2MBX04A.mex05.mlsrvr.com ([fe80::90e2:baff:fe25:106c]) by ORD2HUB34.mex05.mlsrvr.com ([fe80::200:ff:fe00:0%15]) with mapi id 14.03.0169.001; Tue, 12 May 2015 13:50:08 -0500 From: Zack Whittaker To: "publicity@lists.xenproject.org" Thread-Topic: URGENT: Venom flaw re: VirtualBox Thread-Index: AQHQjOKNW8Du8JhbL06AcvEpwriTXp14v+sA Importance: high X-Priority: 1 Date: Tue, 12 May 2015 18:50:07 +0000 Message-ID: <6192179C-277F-4DF5-8888-E26B121170C3@zackwhittaker.co.uk> References: <8961848E-2FCC-459D-AE91-F2C67026EBA4@zackwhittaker.co.uk> In-Reply-To: <8961848E-2FCC-459D-AE91-F2C67026EBA4@zackwhittaker.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.6.0.150113 x-originating-ip: [170.20.11.25] MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 13 May 2015 09:59:00 +0000 Subject: [Publicity] URGENT: Venom flaw re: VirtualBox X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5824123222641280436==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============5824123222641280436== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_" --_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgLS0NCg0KSG9waW5nIHRoaXMgZW1haWwgcmVhY2hlcyBTYXJhaCBDb253YXkuDQoNCkkgc3Bv a2UgdG8gQ3Jvd2RTdHJpa2UgZWFybGllciB0b2RheSBhYm91dCB0aGUgVmVub20gZmxhdyB0aGF0 IHdhcyBmb3VuZCBpbiBRRU1VLCB3aGljaCB3YXMgaW50ZWdyYXRlZCB3aXRoIFhlbi4NCg0KV291 bGQgeW91IGJlIHRoZSBiZXN0IHBlcnNvbiB0byBzaG9vdCBxdWVzdGlvbnMgdG8sIG9yIHdvdWxk IHlvdSBrbm93IG9mIGEgcHJlc3MgcGVyc29uIHRvIHNwZWFrIHRvPw0KDQpMb29raW5nIGZvcndh cmQgdG8gaGVhcmluZyBmcm9tIHlvdS4NCg0KQmVzdCwNClphY2sNCg0KLS0NClphY2sgV2hpdHRh a2VyDQpXcml0ZXItZWRpdG9yOiBaRE5ldDxodHRwOi8vd3d3LnpkbmV0LmNvbS9tZWV0LXRoZS10 ZWFtL3VzL3phY2std2hpdHRha2VyLz4gfCBDTkVUPGh0dHA6Ly93d3cuY25ldC5jb20vcHJvZmls ZS96d2hpdHRha2VyPiB8IENCUyBOZXdzPGh0dHA6Ly93d3cuY2JzbmV3cy5jb20vPg0KMjggRS4g Mjh0aCBTdC4sIE5ldyBZb3JrLCBOWSAxMDAxNg0KKzEgNjQ2IDQyNC00MzgyIChvZmZpY2UpDQor MSA5MjkgNDQ0LTY4MDUgKGNlbGwpDQpAemFja3doaXR0YWtlcjxodHRwczovL3R3aXR0ZXIuY29t L3phY2t3aGl0dGFrZXI+IHwgUEdQOiBFQjZDRUVBNTxodHRwczovL3BncC5taXQuZWR1L3Brcy9s b29rdXA/b3A9Z2V0JnNlYXJjaD0weENCOEMxNUZBRUI2Q0VFQTU+DQo= --_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_ Content-Type: text/html; charset="utf-8" Content-ID: <835A5B3DF8540F428CFAC301DD112BF0@mex05.mlsrvr.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIC0tJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+SG9waW5nIHRoaXMgZW1haWwgcmVhY2hlcyBTYXJhaCBDb253YXkuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pkkgc3Bva2UgdG8gQ3Jvd2RTdHJpa2UgZWFybGllciB0b2Rh eSBhYm91dCB0aGUgVmVub20gZmxhdyB0aGF0IHdhcyBmb3VuZCBpbiBRRU1VLCB3aGljaCB3YXMg aW50ZWdyYXRlZCB3aXRoIFhlbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldvdWxk IHlvdSBiZSB0aGUgYmVzdCBwZXJzb24gdG8gc2hvb3QgcXVlc3Rpb25zIHRvLCBvciB3b3VsZCB5 b3Uga25vdyBvZiBhIHByZXNzIHBlcnNvbiB0byBzcGVhayB0bz88L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pkxvb2tpbmcgZm9yd2FyZCB0byBoZWFyaW5nIGZyb20geW91LjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVzdCw8L2Rpdj4NCjxkaXY+WmFjayZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+DQo8ZGl2Pi0tPC9kaXY+DQo8ZGl2PjxiPlphY2sg V2hpdHRha2VyPC9iPjwvZGl2Pg0KPGRpdj5Xcml0ZXItZWRpdG9yOiZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly93d3cuemRuZXQuY29tL21lZXQtdGhlLXRlYW0vdXMvemFjay13aGl0dGFrZXIvIj5aRE5l dDwvYT4mbmJzcDt8Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5jbmV0LmNvbS9wcm9maWxlL3p3 aGl0dGFrZXIiPkNORVQ8L2E+Jm5ic3A7fCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuY2JzbmV3 cy5jb20vIj5DQlMgTmV3czwvYT48L2Rpdj4NCjxkaXY+MjggRS4gMjh0aCBTdC4sIE5ldyBZb3Jr LCBOWSAxMDAxNjwvZGl2Pg0KPGRpdj4mIzQzOzEgNjQ2IDQyNC00MzgyIChvZmZpY2UpPC9kaXY+ DQo8ZGl2PiYjNDM7MSA5MjkgNDQ0LTY4MDUgKGNlbGwpPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0 dHBzOi8vdHdpdHRlci5jb20vemFja3doaXR0YWtlciI+QHphY2t3aGl0dGFrZXI8L2E+Jm5ic3A7 fCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vcGdwLm1pdC5lZHUvcGtzL2xvb2t1cD9vcD1nZXQmYW1w O3NlYXJjaD0weENCOEMxNUZBRUI2Q0VFQTUiPlBHUDombmJzcDtFQjZDRUVBNTwvYT48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_-- --===============5824123222641280436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============5824123222641280436==-- From publicity-bounces@lists.xenproject.org Wed May 13 09:59:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 May 2015 09:59:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsTRO-00013U-3p; Wed, 13 May 2015 09:59:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsFFt-00030i-2h for publicity@lists.xenproject.org; Tue, 12 May 2015 18:50:13 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 2E/24-03561-46B42555; Tue, 12 May 2015 18:50:12 +0000 X-Env-Sender: zack@zackwhittaker.co.uk X-Msg-Ref: server-12.tower-206.messagelabs.com!1431456609!14475457!1 X-Originating-IP: [108.166.43.126] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8706 invoked from network); 12 May 2015 18:50:09 -0000 Received: from smtp126.ord1c.emailsrvr.com (HELO smtp126.ord1c.emailsrvr.com) (108.166.43.126) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 May 2015 18:50:09 -0000 Received: from smtp16.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C75BF180382 for ; Tue, 12 May 2015 14:50:08 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp16.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B9D5B1801C0 for ; Tue, 12 May 2015 14:50:08 -0400 (EDT) Received: from smtp192.mex05.mlsrvr.com (unknown [184.106.31.85]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTPS id A50BC180402 for ; Tue, 12 May 2015 14:50:08 -0400 (EDT) X-Sender-Id: zack@zackwhittaker.co.uk Received: from smtp192.mex05.mlsrvr.com ([UNAVAILABLE]. [184.106.31.85]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:25 (trex/5.4.2); Tue, 12 May 2015 18:50:08 GMT Received: from ORD2MBX04A.mex05.mlsrvr.com ([fe80::90e2:baff:fe25:106c]) by ORD2HUB34.mex05.mlsrvr.com ([fe80::200:ff:fe00:0%15]) with mapi id 14.03.0169.001; Tue, 12 May 2015 13:50:08 -0500 From: Zack Whittaker To: "publicity@lists.xenproject.org" Thread-Topic: URGENT: Venom flaw re: VirtualBox Thread-Index: AQHQjOKNW8Du8JhbL06AcvEpwriTXp14v+sA Importance: high X-Priority: 1 Date: Tue, 12 May 2015 18:50:07 +0000 Message-ID: <6192179C-277F-4DF5-8888-E26B121170C3@zackwhittaker.co.uk> References: <8961848E-2FCC-459D-AE91-F2C67026EBA4@zackwhittaker.co.uk> In-Reply-To: <8961848E-2FCC-459D-AE91-F2C67026EBA4@zackwhittaker.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.6.0.150113 x-originating-ip: [170.20.11.25] MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 13 May 2015 09:59:00 +0000 Subject: [Publicity] URGENT: Venom flaw re: VirtualBox X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5824123222641280436==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============5824123222641280436== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_" --_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgLS0NCg0KSG9waW5nIHRoaXMgZW1haWwgcmVhY2hlcyBTYXJhaCBDb253YXkuDQoNCkkgc3Bv a2UgdG8gQ3Jvd2RTdHJpa2UgZWFybGllciB0b2RheSBhYm91dCB0aGUgVmVub20gZmxhdyB0aGF0 IHdhcyBmb3VuZCBpbiBRRU1VLCB3aGljaCB3YXMgaW50ZWdyYXRlZCB3aXRoIFhlbi4NCg0KV291 bGQgeW91IGJlIHRoZSBiZXN0IHBlcnNvbiB0byBzaG9vdCBxdWVzdGlvbnMgdG8sIG9yIHdvdWxk IHlvdSBrbm93IG9mIGEgcHJlc3MgcGVyc29uIHRvIHNwZWFrIHRvPw0KDQpMb29raW5nIGZvcndh cmQgdG8gaGVhcmluZyBmcm9tIHlvdS4NCg0KQmVzdCwNClphY2sNCg0KLS0NClphY2sgV2hpdHRh a2VyDQpXcml0ZXItZWRpdG9yOiBaRE5ldDxodHRwOi8vd3d3LnpkbmV0LmNvbS9tZWV0LXRoZS10 ZWFtL3VzL3phY2std2hpdHRha2VyLz4gfCBDTkVUPGh0dHA6Ly93d3cuY25ldC5jb20vcHJvZmls ZS96d2hpdHRha2VyPiB8IENCUyBOZXdzPGh0dHA6Ly93d3cuY2JzbmV3cy5jb20vPg0KMjggRS4g Mjh0aCBTdC4sIE5ldyBZb3JrLCBOWSAxMDAxNg0KKzEgNjQ2IDQyNC00MzgyIChvZmZpY2UpDQor MSA5MjkgNDQ0LTY4MDUgKGNlbGwpDQpAemFja3doaXR0YWtlcjxodHRwczovL3R3aXR0ZXIuY29t L3phY2t3aGl0dGFrZXI+IHwgUEdQOiBFQjZDRUVBNTxodHRwczovL3BncC5taXQuZWR1L3Brcy9s b29rdXA/b3A9Z2V0JnNlYXJjaD0weENCOEMxNUZBRUI2Q0VFQTU+DQo= --_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_ Content-Type: text/html; charset="utf-8" Content-ID: <835A5B3DF8540F428CFAC301DD112BF0@mex05.mlsrvr.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIC0tJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+SG9waW5nIHRoaXMgZW1haWwgcmVhY2hlcyBTYXJhaCBDb253YXkuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pkkgc3Bva2UgdG8gQ3Jvd2RTdHJpa2UgZWFybGllciB0b2Rh eSBhYm91dCB0aGUgVmVub20gZmxhdyB0aGF0IHdhcyBmb3VuZCBpbiBRRU1VLCB3aGljaCB3YXMg aW50ZWdyYXRlZCB3aXRoIFhlbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldvdWxk IHlvdSBiZSB0aGUgYmVzdCBwZXJzb24gdG8gc2hvb3QgcXVlc3Rpb25zIHRvLCBvciB3b3VsZCB5 b3Uga25vdyBvZiBhIHByZXNzIHBlcnNvbiB0byBzcGVhayB0bz88L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pkxvb2tpbmcgZm9yd2FyZCB0byBoZWFyaW5nIGZyb20geW91LjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVzdCw8L2Rpdj4NCjxkaXY+WmFjayZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+DQo8ZGl2Pi0tPC9kaXY+DQo8ZGl2PjxiPlphY2sg V2hpdHRha2VyPC9iPjwvZGl2Pg0KPGRpdj5Xcml0ZXItZWRpdG9yOiZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly93d3cuemRuZXQuY29tL21lZXQtdGhlLXRlYW0vdXMvemFjay13aGl0dGFrZXIvIj5aRE5l dDwvYT4mbmJzcDt8Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5jbmV0LmNvbS9wcm9maWxlL3p3 aGl0dGFrZXIiPkNORVQ8L2E+Jm5ic3A7fCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuY2JzbmV3 cy5jb20vIj5DQlMgTmV3czwvYT48L2Rpdj4NCjxkaXY+MjggRS4gMjh0aCBTdC4sIE5ldyBZb3Jr LCBOWSAxMDAxNjwvZGl2Pg0KPGRpdj4mIzQzOzEgNjQ2IDQyNC00MzgyIChvZmZpY2UpPC9kaXY+ DQo8ZGl2PiYjNDM7MSA5MjkgNDQ0LTY4MDUgKGNlbGwpPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0 dHBzOi8vdHdpdHRlci5jb20vemFja3doaXR0YWtlciI+QHphY2t3aGl0dGFrZXI8L2E+Jm5ic3A7 fCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vcGdwLm1pdC5lZHUvcGtzL2xvb2t1cD9vcD1nZXQmYW1w O3NlYXJjaD0weENCOEMxNUZBRUI2Q0VFQTUiPlBHUDombmJzcDtFQjZDRUVBNTwvYT48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6192179C277F4DF58888E26B121170C3zackwhittakercouk_-- --===============5824123222641280436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============5824123222641280436==-- From publicity-bounces@lists.xenproject.org Wed May 13 10:38:43 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 May 2015 10:38:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsU3m-0004BT-Up; Wed, 13 May 2015 10:38:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsU3m-0004BO-03 for publicity@lists.xenproject.org; Wed, 13 May 2015 10:38:42 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id DD/64-03032-1B923555; Wed, 13 May 2015 10:38:41 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1431513518!17193021!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22812 invoked from network); 13 May 2015 10:38:39 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2015 10:38:39 -0000 Received: by wicmx19 with SMTP id mx19so7327979wic.0 for ; Wed, 13 May 2015 03:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=x2ONJgpw9+wNIF1bcVH+BMNHppaF0SF8/or1IeTsjpo=; b=Gv49H2gilF/iuvOHxFOw6ASEbvJPDd4ck/+ip95QYz1A2oIADCslXzJrl81r0krpeq f2QRTZ690A24GmeQkVAkvokWAodxNyDn0cNUW7S5XPnFGTXw3zPL276sWIXdfne1lEC5 RN98t/5u1Clr1TMceFcFsEObDZZxXLREJ48/ErQhRP4GJ7Dg11qbQ2x24Csyyk79sZmq Tw5y5ScCbhobpldK5usKOOg6mt25NBidz4BFFvk46GlfukwSkraWqbVO4/r4e8bmHhhY 52tBc6zijB1YaQFt+Iv41Mwx1PvazEFKBpXyBN6YWpFhvb8bmOWpI3AHeJWum8MyFMXH rQLQ== X-Received: by 10.180.98.230 with SMTP id el6mr36578436wib.16.1431513518641; Wed, 13 May 2015 03:38:38 -0700 (PDT) Received: from [192.168.0.12] (97e3cdda.skybroadband.com. [151.227.205.218]) by mx.google.com with ESMTPSA id l6sm32238896wjz.4.2015.05.13.03.38.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 May 2015 03:38:37 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth X-Priority: 1 In-Reply-To: <6192179C-277F-4DF5-8888-E26B121170C3@zackwhittaker.co.uk> Date: Wed, 13 May 2015 11:38:36 +0100 Message-Id: <55B64980-F8DD-4BA6-8F49-2D766C88966C@gmail.com> References: <8961848E-2FCC-459D-AE91-F2C67026EBA4@zackwhittaker.co.uk> <6192179C-277F-4DF5-8888-E26B121170C3@zackwhittaker.co.uk> To: Zack Whittaker X-Mailer: Apple Mail (2.2098) Cc: "publicity@lists.xenproject.org" Subject: Re: [Publicity] URGENT: Venom flaw re: VirtualBox X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5716038608024050820==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============5716038608024050820== Content-Type: multipart/alternative; boundary="Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8" --Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Zack, Sarah received the mail yesterday and consequently we consulted the = security team. Here is the response. The Xen Project Security team cannot discuss _any_ details of what = people have told us under embargo except: - when coopting technical assistance; - when an XSA is predisclosed (and then only to the list members of the = Xen Project Pre-Disclosure List - see URL below); and - when an XSA has been released. That extends to not discussing what we _haven't_ been told as well. The = only information we make public is the assignment of numbers. You can see from http://xenbits.xen.org/xsa/ = that XSA-133 will be released today at = 12:00 UTC, with details of an unspecified vulnerability. You can find more information about the Xen Project's Security = Vulnerability Process at http://www.xenproject.org/security-policy.html = Best Regards Lars > On 12 May 2015, at 19:50, Zack Whittaker = wrote: >=20 > Hi --=20 >=20 > Hoping this email reaches Sarah Conway. >=20 > I spoke to CrowdStrike earlier today about the Venom flaw that was = found in QEMU, which was integrated with Xen. >=20 > Would you be the best person to shoot questions to, or would you know = of a press person to speak to? >=20 > Looking forward to hearing from you. >=20 > Best, > Zack=20 >=20 > -- > Zack Whittaker > Writer-editor: ZDNet = | CNET = | CBS News = > 28 E. 28th St., New York, NY 10016 > +1 646 424-4382 (office) > +1 929 444-6805 (cell) > @zackwhittaker | PGP:=C2=A0EB6CEEA5 = _____= __________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Zack,

Sarah= received the mail yesterday and consequently we consulted the security = team. Here is the response.

The Xen Project Security team cannot discuss _any_ details = of what people have told us under embargo except:
- = when coopting technical assistance;
- when an XSA is = predisclosed (and then only to the list members of the Xen Project = Pre-Disclosure List - see URL below); and
- when an XSA = has been released.

That extends to not = discussing what we _haven't_ been told as well. The only = information we make public is the assignment of numbers.
You= can see from http://xenbits.xen.org/xsa/ that XSA-133 will = be released today at 12:00 UTC, with details of an unspecified = vulnerability.

You can find more information about the Xen Project's = Security Vulnerability Process at http://www.xenproject.org/security-policy.html

Best Regards
Lars

On 12 May 2015, at 19:50, Zack = Whittaker <zack@zackwhittaker.co.uk> wrote:

Hi -- 

Hoping this email reaches Sarah Conway.

I spoke to CrowdStrike earlier today about the Venom = flaw that was found in QEMU, which was integrated with Xen.

Would you be the best person to shoot questions to, or = would you know of a press person to speak to?

Looking forward to hearing from you.

Best,
Zack 

--
Zack Whittaker
Writer-editor: ZDNet | CNET | CBS News
28 E. 28th St., New York, NY 10016
+1 646 424-4382 (office)
+1 929 444-6805 (cell)
@zackwhittaker | PGP: EB6CEEA5
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= br class=3D"">

= --Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8-- --===============5716038608024050820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============5716038608024050820==-- From publicity-bounces@lists.xenproject.org Wed May 13 10:38:43 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 May 2015 10:38:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsU3m-0004BT-Up; Wed, 13 May 2015 10:38:42 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsU3m-0004BO-03 for publicity@lists.xenproject.org; Wed, 13 May 2015 10:38:42 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id DD/64-03032-1B923555; Wed, 13 May 2015 10:38:41 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1431513518!17193021!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22812 invoked from network); 13 May 2015 10:38:39 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2015 10:38:39 -0000 Received: by wicmx19 with SMTP id mx19so7327979wic.0 for ; Wed, 13 May 2015 03:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=x2ONJgpw9+wNIF1bcVH+BMNHppaF0SF8/or1IeTsjpo=; b=Gv49H2gilF/iuvOHxFOw6ASEbvJPDd4ck/+ip95QYz1A2oIADCslXzJrl81r0krpeq f2QRTZ690A24GmeQkVAkvokWAodxNyDn0cNUW7S5XPnFGTXw3zPL276sWIXdfne1lEC5 RN98t/5u1Clr1TMceFcFsEObDZZxXLREJ48/ErQhRP4GJ7Dg11qbQ2x24Csyyk79sZmq Tw5y5ScCbhobpldK5usKOOg6mt25NBidz4BFFvk46GlfukwSkraWqbVO4/r4e8bmHhhY 52tBc6zijB1YaQFt+Iv41Mwx1PvazEFKBpXyBN6YWpFhvb8bmOWpI3AHeJWum8MyFMXH rQLQ== X-Received: by 10.180.98.230 with SMTP id el6mr36578436wib.16.1431513518641; Wed, 13 May 2015 03:38:38 -0700 (PDT) Received: from [192.168.0.12] (97e3cdda.skybroadband.com. [151.227.205.218]) by mx.google.com with ESMTPSA id l6sm32238896wjz.4.2015.05.13.03.38.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 May 2015 03:38:37 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth X-Priority: 1 In-Reply-To: <6192179C-277F-4DF5-8888-E26B121170C3@zackwhittaker.co.uk> Date: Wed, 13 May 2015 11:38:36 +0100 Message-Id: <55B64980-F8DD-4BA6-8F49-2D766C88966C@gmail.com> References: <8961848E-2FCC-459D-AE91-F2C67026EBA4@zackwhittaker.co.uk> <6192179C-277F-4DF5-8888-E26B121170C3@zackwhittaker.co.uk> To: Zack Whittaker X-Mailer: Apple Mail (2.2098) Cc: "publicity@lists.xenproject.org" Subject: Re: [Publicity] URGENT: Venom flaw re: VirtualBox X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5716038608024050820==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============5716038608024050820== Content-Type: multipart/alternative; boundary="Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8" --Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Zack, Sarah received the mail yesterday and consequently we consulted the = security team. Here is the response. The Xen Project Security team cannot discuss _any_ details of what = people have told us under embargo except: - when coopting technical assistance; - when an XSA is predisclosed (and then only to the list members of the = Xen Project Pre-Disclosure List - see URL below); and - when an XSA has been released. That extends to not discussing what we _haven't_ been told as well. The = only information we make public is the assignment of numbers. You can see from http://xenbits.xen.org/xsa/ = that XSA-133 will be released today at = 12:00 UTC, with details of an unspecified vulnerability. You can find more information about the Xen Project's Security = Vulnerability Process at http://www.xenproject.org/security-policy.html = Best Regards Lars > On 12 May 2015, at 19:50, Zack Whittaker = wrote: >=20 > Hi --=20 >=20 > Hoping this email reaches Sarah Conway. >=20 > I spoke to CrowdStrike earlier today about the Venom flaw that was = found in QEMU, which was integrated with Xen. >=20 > Would you be the best person to shoot questions to, or would you know = of a press person to speak to? >=20 > Looking forward to hearing from you. >=20 > Best, > Zack=20 >=20 > -- > Zack Whittaker > Writer-editor: ZDNet = | CNET = | CBS News = > 28 E. 28th St., New York, NY 10016 > +1 646 424-4382 (office) > +1 929 444-6805 (cell) > @zackwhittaker | PGP:=C2=A0EB6CEEA5 = _____= __________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Zack,

Sarah= received the mail yesterday and consequently we consulted the security = team. Here is the response.

The Xen Project Security team cannot discuss _any_ details = of what people have told us under embargo except:
- = when coopting technical assistance;
- when an XSA is = predisclosed (and then only to the list members of the Xen Project = Pre-Disclosure List - see URL below); and
- when an XSA = has been released.

That extends to not = discussing what we _haven't_ been told as well. The only = information we make public is the assignment of numbers.
You= can see from http://xenbits.xen.org/xsa/ that XSA-133 will = be released today at 12:00 UTC, with details of an unspecified = vulnerability.

You can find more information about the Xen Project's = Security Vulnerability Process at http://www.xenproject.org/security-policy.html

Best Regards
Lars

On 12 May 2015, at 19:50, Zack = Whittaker <zack@zackwhittaker.co.uk> wrote:

Hi -- 

Hoping this email reaches Sarah Conway.

I spoke to CrowdStrike earlier today about the Venom = flaw that was found in QEMU, which was integrated with Xen.

Would you be the best person to shoot questions to, or = would you know of a press person to speak to?

Looking forward to hearing from you.

Best,
Zack 

--
Zack Whittaker
Writer-editor: ZDNet | CNET | CBS News
28 E. 28th St., New York, NY 10016
+1 646 424-4382 (office)
+1 929 444-6805 (cell)
@zackwhittaker | PGP: EB6CEEA5
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= br class=3D"">

= --Apple-Mail=_BB92381C-D391-4C6C-9350-4B932132CCE8-- --===============5716038608024050820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============5716038608024050820==-- From publicity-bounces@lists.xenproject.org Wed May 13 20:30:42 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 May 2015 20:30:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsdIf-00009R-AW; Wed, 13 May 2015 20:30:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsdEr-0008UB-33 for publicity@lists.xenproject.org; Wed, 13 May 2015 20:26:45 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id D2/70-02927-383B3555; Wed, 13 May 2015 20:26:43 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1431548802!15177673!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13660 invoked from network); 13 May 2015 20:26:42 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2015 20:26:42 -0000 Received: by wgbhc8 with SMTP id hc8so21458928wgb.3 for ; Wed, 13 May 2015 13:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=gq7NR10m+WFm2fveIzVb8kmcN/dvuV6mtOwvHTWiUlE=; b=Ev5EuXMdpfIZ9a2zkHqWNBszTRuyQtH29f7yWw5d819tEOa8Jvf0gT+a1og7t2Zfpg 0te/1c0xbzmfxi4h78o2y1kpVoq2c7m4m5gkfuzB+4O68fL4PZcrArrma2hGZuMvrlMg 14uIqXpNkHXo97yza3bb02dhsRNCuQYqb/gg3gSVYkK0ejh5vxdWLn6v1eZootYz9XKG dW1CzP6jcrFT6RYdgCjn55WWis6ocxM4sS+nZwBUT7qPPN1cPhnkcnBjC37OaxnC7ccn fd9lV1zVbeHI2CvI1N3nIddUxjxkpVQdIw/snWZm+Yb1FxZeSOhlQ1ybusLn5B3cmj3y 2lJA== X-Gm-Message-State: ALoCoQmRN7EWDn4YOrQJUeLCB0hlqC61MhXzqovB8xNzmGGzxu2YK7+EKMauSFpf+HBC07cLEkpw MIME-Version: 1.0 X-Received: by 10.180.106.226 with SMTP id gx2mr41287319wib.48.1431548801643; Wed, 13 May 2015 13:26:41 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Wed, 13 May 2015 13:26:41 -0700 (PDT) Date: Wed, 13 May 2015 22:26:41 +0200 Message-ID: From: "Lengyel, Tamas" To: publicity@lists.xenproject.org X-Mailman-Approved-At: Wed, 13 May 2015 20:30:40 +0000 Subject: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2742838774744057096==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============2742838774744057096== Content-Type: multipart/alternative; boundary=e89a8f3bad4bcd0ea90515fc6dd0 --e89a8f3bad4bcd0ea90515fc6dd0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everyone, I've put together a quick blog entry to remind people that using stubdomains can address issues with QEMU, like the new VENOM vulnerability. Let me know if it would be appropriate for the Xen blog (or if you have any comments)! Thanks, Tamas Hardening Xen against VENOM-style attacks The recent disclosure of the VENOM bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating in the tech news lately, causing many to reevaluate their security posture when using cloud infrastructures. That is a very good thing indeed. Virtualization and the cloud has been for too long erroneously considered to be a silver bullet against intrusions, malware and APTs. The cloud is anything but a safe place. VENOM in that sense is just another one in the long list of vulnerabilities that seem to be plaguing hypervisors. However, there are differences between vulnerabilities. While VENOM is indeed a serious bug and can result in a VM escape, which can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fact, VEN= OM-style attacks have been known for a long time. And there are easy-to-deploy counter-measures to mitigate the risk of such exploits, natively available in Xen and KVM. What is the root cause of VENOM? Emulation. While modern systems come with a plethora of virtualization extensions, many components are still being emulated. The biggest component of that are usually devices. Devices such as your network card, graphics card and your hard drive. While Linux comes with paravirtual (virtualization-aware) drivers to create such devices, emulation is often the only solution to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows. This emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent years. However, QEMU is not the only place where emulation is used within Xen. For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for performance and scalability reasons. As with QEMU, this emulator has been just as exploitable. This is simply because emulating devices and services is really complex and error-prone to program properly. This fact, that emulation is complex and error-prone, has been known for a long time. Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM escape attack against KVM, through QEMU. The author of Virtunoid even cautioned that there will be many other bugs of that nature found by researchers. Fast-forward 4 years and we now have VENOM. The good news is that there is an easy mitigation available for all present and future QEMU bugs, also mentioned in the original Xen Security Advisory. It is called stubdomains. Stubdomains can nip the whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU into a deprivileged domain of its own. Instead of having QEMU run as root in dom0, a stubdomain has access only to the VM it is providing emulation for. Thus, an escape through QEMU will only land an attacker in a stubdomain, without access to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an attacker would only have a very limited environment to run code in (as in return-to-libc/ROP-style), having exactly the same level of privilege as in the domain where the attack started. Nothing to be gained for a lot of work, effectively making the system as secure as it would be if only PV drivers were used. As a sidenote, KVM allows for similar jailing of the QEMU process via the native SELinux sVirt policies. One would think it is a complex process to take advantage of this protection, when it is, in fact, very simple. Add the following line to your Xen domain configuration and you gain immediate protection against VENOM, and the whole class of vulnerabilities brought to you by QEMU: device_model_stubdomain_override =3D 1 Unfortunately, your cloud provider may not allow you to enable this option. They certainly should, so complain loudly and repeatedly if that=E2=80=99s = the case. There is no reason to keep this class of bugs alive. --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --e89a8f3bad4bcd0ea90515fc6dd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Everyone,

I've put together a quick blog entry to remind people that using = stubdomains can address issues with QEMU, like the new VENOM vulnerability.= Let me know if it would be appropriate for the Xen blog (or if you have an= y comments)!

Thanks,

Tamas


Hardening Xen against VENOM-style attacks


The recent disclosure of the VENOM bug affecting major open= -source hypervisors, such as KVM and Xen, has been circulating in the tech = news lately, causing many to reevaluate their security posture when using c= loud infrastructures. That is a very good thing indeed. Virtualization and = the cloud has been for too long erroneously considered to be a silver bulle= t against intrusions, malware and APTs.


The cloud is anything but a safe place. VENOM in= that sense is just another one in the long list of vulnerabilities that se= em to be plaguing hypervisors. However, there are differences between vulne= rabilities. While VENOM is indeed a serious bug and can result in a VM esca= pe, which can compromise all VMs on the host, it doesn=E2=80=99t have to be= . In fact, VENOM-style attacks have been known for a long time. And there a= re easy-to-deploy counter-measures to mitigate the risk of such exploits, n= atively available in Xen and KVM.


What is the root cause of VENOM? Emulation.

<= br>

While modern systems come= with a plethora of virtualization extensions, many components are still be= ing emulated. The biggest component of that are usually devices. Devices such as your network card, graphics card an= d your hard drive. While Linux comes with paravirtual (virtualization-aware= ) drivers to create such devices, emulation is often the only solution to r= un operating systems that do not have such kernel drivers. This has been tr= aditionally the case with Windows. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. However= , QEMU is not the only place where emulation is used within Xen. For a vari= ety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC = and LAPIC, there is a baked-in emulator in Xen itself for performance and s= calability reasons. A= s with QEMU, this emulator has been just as exploitable. This is simply because emulating devi= ces and services is really complex and error-prone to program properly.


This fact, that = emulation is complex and error-prone, has been known for a long time. Back = in 2011, the Blackhat talk on Virtunoid demonstrated such a VM escape attack against KVM, throug= h QEMU. The author of Virtunoid even cautioned that there will be many othe= r bugs of that nature found by researchers. Fast-forward 4 years and we now= have VENOM.


T= he good news is that there is an easy mitigation available for all present = and future QEMU bugs, also mentioned in the original Xen Security Advisory<= /span>. It is called = stubdomains. Stubdomains can nip the whole class o= f vulnerabilities exposed by QEMU in the bud by moving QEMU into a deprivil= eged domain of its own. Instead of having QEMU run as root in dom0, a stubd= omain has access only to the VM it is providing emulation for. Thus, an esc= ape through QEMU will only land an attacker in a stubdomain, without access= to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an attacker would only have a very limit= ed environment to run code in (as in return-to-libc/ROP-style), having exac= tly the same level of privilege as in the domain where the attack started. = Nothing to be gained for a lot of work, effectively making the system as se= cure as it would be if only PV drivers were used. As a sidenote, KVM allows= for similar jailing of the QEMU process via the native SELinux sVirt polic= ies.


One would think it is a comple= x process to take advantage of this protection, when it is, in fact, very s= imple. Add the following line to your Xen domain configuration and you gain= immediate protection against VENOM, and the whole class of vulnerabilities= brought to you by QEMU:

device_model_stubdomain_ove= rride =3D 1


U= nfortunately, your cloud provider may not allow you to enable this option. = They certainly should, so complain loudly and repeatedly if that=E2=80=99s = the case. There is no reason to keep this class of bugs alive.


--
=

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--e89a8f3bad4bcd0ea90515fc6dd0-- --===============2742838774744057096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============2742838774744057096==-- From publicity-bounces@lists.xenproject.org Wed May 13 20:30:42 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 May 2015 20:30:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsdIf-00009R-AW; Wed, 13 May 2015 20:30:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsdEr-0008UB-33 for publicity@lists.xenproject.org; Wed, 13 May 2015 20:26:45 +0000 Received: from [85.158.137.68] by server-17.bemta-3.messagelabs.com id D2/70-02927-383B3555; Wed, 13 May 2015 20:26:43 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1431548802!15177673!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13660 invoked from network); 13 May 2015 20:26:42 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 May 2015 20:26:42 -0000 Received: by wgbhc8 with SMTP id hc8so21458928wgb.3 for ; Wed, 13 May 2015 13:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=gq7NR10m+WFm2fveIzVb8kmcN/dvuV6mtOwvHTWiUlE=; b=Ev5EuXMdpfIZ9a2zkHqWNBszTRuyQtH29f7yWw5d819tEOa8Jvf0gT+a1og7t2Zfpg 0te/1c0xbzmfxi4h78o2y1kpVoq2c7m4m5gkfuzB+4O68fL4PZcrArrma2hGZuMvrlMg 14uIqXpNkHXo97yza3bb02dhsRNCuQYqb/gg3gSVYkK0ejh5vxdWLn6v1eZootYz9XKG dW1CzP6jcrFT6RYdgCjn55WWis6ocxM4sS+nZwBUT7qPPN1cPhnkcnBjC37OaxnC7ccn fd9lV1zVbeHI2CvI1N3nIddUxjxkpVQdIw/snWZm+Yb1FxZeSOhlQ1ybusLn5B3cmj3y 2lJA== X-Gm-Message-State: ALoCoQmRN7EWDn4YOrQJUeLCB0hlqC61MhXzqovB8xNzmGGzxu2YK7+EKMauSFpf+HBC07cLEkpw MIME-Version: 1.0 X-Received: by 10.180.106.226 with SMTP id gx2mr41287319wib.48.1431548801643; Wed, 13 May 2015 13:26:41 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Wed, 13 May 2015 13:26:41 -0700 (PDT) Date: Wed, 13 May 2015 22:26:41 +0200 Message-ID: From: "Lengyel, Tamas" To: publicity@lists.xenproject.org X-Mailman-Approved-At: Wed, 13 May 2015 20:30:40 +0000 Subject: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2742838774744057096==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============2742838774744057096== Content-Type: multipart/alternative; boundary=e89a8f3bad4bcd0ea90515fc6dd0 --e89a8f3bad4bcd0ea90515fc6dd0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everyone, I've put together a quick blog entry to remind people that using stubdomains can address issues with QEMU, like the new VENOM vulnerability. Let me know if it would be appropriate for the Xen blog (or if you have any comments)! Thanks, Tamas Hardening Xen against VENOM-style attacks The recent disclosure of the VENOM bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating in the tech news lately, causing many to reevaluate their security posture when using cloud infrastructures. That is a very good thing indeed. Virtualization and the cloud has been for too long erroneously considered to be a silver bullet against intrusions, malware and APTs. The cloud is anything but a safe place. VENOM in that sense is just another one in the long list of vulnerabilities that seem to be plaguing hypervisors. However, there are differences between vulnerabilities. While VENOM is indeed a serious bug and can result in a VM escape, which can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fact, VEN= OM-style attacks have been known for a long time. And there are easy-to-deploy counter-measures to mitigate the risk of such exploits, natively available in Xen and KVM. What is the root cause of VENOM? Emulation. While modern systems come with a plethora of virtualization extensions, many components are still being emulated. The biggest component of that are usually devices. Devices such as your network card, graphics card and your hard drive. While Linux comes with paravirtual (virtualization-aware) drivers to create such devices, emulation is often the only solution to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows. This emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent years. However, QEMU is not the only place where emulation is used within Xen. For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for performance and scalability reasons. As with QEMU, this emulator has been just as exploitable. This is simply because emulating devices and services is really complex and error-prone to program properly. This fact, that emulation is complex and error-prone, has been known for a long time. Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM escape attack against KVM, through QEMU. The author of Virtunoid even cautioned that there will be many other bugs of that nature found by researchers. Fast-forward 4 years and we now have VENOM. The good news is that there is an easy mitigation available for all present and future QEMU bugs, also mentioned in the original Xen Security Advisory. It is called stubdomains. Stubdomains can nip the whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU into a deprivileged domain of its own. Instead of having QEMU run as root in dom0, a stubdomain has access only to the VM it is providing emulation for. Thus, an escape through QEMU will only land an attacker in a stubdomain, without access to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an attacker would only have a very limited environment to run code in (as in return-to-libc/ROP-style), having exactly the same level of privilege as in the domain where the attack started. Nothing to be gained for a lot of work, effectively making the system as secure as it would be if only PV drivers were used. As a sidenote, KVM allows for similar jailing of the QEMU process via the native SELinux sVirt policies. One would think it is a complex process to take advantage of this protection, when it is, in fact, very simple. Add the following line to your Xen domain configuration and you gain immediate protection against VENOM, and the whole class of vulnerabilities brought to you by QEMU: device_model_stubdomain_override =3D 1 Unfortunately, your cloud provider may not allow you to enable this option. They certainly should, so complain loudly and repeatedly if that=E2=80=99s = the case. There is no reason to keep this class of bugs alive. --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --e89a8f3bad4bcd0ea90515fc6dd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Everyone,

I've put together a quick blog entry to remind people that using = stubdomains can address issues with QEMU, like the new VENOM vulnerability.= Let me know if it would be appropriate for the Xen blog (or if you have an= y comments)!

Thanks,

Tamas


Hardening Xen against VENOM-style attacks


The recent disclosure of the VENOM bug affecting major open= -source hypervisors, such as KVM and Xen, has been circulating in the tech = news lately, causing many to reevaluate their security posture when using c= loud infrastructures. That is a very good thing indeed. Virtualization and = the cloud has been for too long erroneously considered to be a silver bulle= t against intrusions, malware and APTs.


The cloud is anything but a safe place. VENOM in= that sense is just another one in the long list of vulnerabilities that se= em to be plaguing hypervisors. However, there are differences between vulne= rabilities. While VENOM is indeed a serious bug and can result in a VM esca= pe, which can compromise all VMs on the host, it doesn=E2=80=99t have to be= . In fact, VENOM-style attacks have been known for a long time. And there a= re easy-to-deploy counter-measures to mitigate the risk of such exploits, n= atively available in Xen and KVM.


What is the root cause of VENOM? Emulation.

<= br>

While modern systems come= with a plethora of virtualization extensions, many components are still be= ing emulated. The biggest component of that are usually devices. Devices such as your network card, graphics card an= d your hard drive. While Linux comes with paravirtual (virtualization-aware= ) drivers to create such devices, emulation is often the only solution to r= un operating systems that do not have such kernel drivers. This has been tr= aditionally the case with Windows. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. However= , QEMU is not the only place where emulation is used within Xen. For a vari= ety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC = and LAPIC, there is a baked-in emulator in Xen itself for performance and s= calability reasons. A= s with QEMU, this emulator has been just as exploitable. This is simply because emulating devi= ces and services is really complex and error-prone to program properly.


This fact, that = emulation is complex and error-prone, has been known for a long time. Back = in 2011, the Blackhat talk on Virtunoid demonstrated such a VM escape attack against KVM, throug= h QEMU. The author of Virtunoid even cautioned that there will be many othe= r bugs of that nature found by researchers. Fast-forward 4 years and we now= have VENOM.


T= he good news is that there is an easy mitigation available for all present = and future QEMU bugs, also mentioned in the original Xen Security Advisory<= /span>. It is called = stubdomains. Stubdomains can nip the whole class o= f vulnerabilities exposed by QEMU in the bud by moving QEMU into a deprivil= eged domain of its own. Instead of having QEMU run as root in dom0, a stubd= omain has access only to the VM it is providing emulation for. Thus, an esc= ape through QEMU will only land an attacker in a stubdomain, without access= to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an attacker would only have a very limit= ed environment to run code in (as in return-to-libc/ROP-style), having exac= tly the same level of privilege as in the domain where the attack started. = Nothing to be gained for a lot of work, effectively making the system as se= cure as it would be if only PV drivers were used. As a sidenote, KVM allows= for similar jailing of the QEMU process via the native SELinux sVirt polic= ies.


One would think it is a comple= x process to take advantage of this protection, when it is, in fact, very s= imple. Add the following line to your Xen domain configuration and you gain= immediate protection against VENOM, and the whole class of vulnerabilities= brought to you by QEMU:

device_model_stubdomain_ove= rride =3D 1


U= nfortunately, your cloud provider may not allow you to enable this option. = They certainly should, so complain loudly and repeatedly if that=E2=80=99s = the case. There is no reason to keep this class of bugs alive.


--
=

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--e89a8f3bad4bcd0ea90515fc6dd0-- --===============2742838774744057096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============2742838774744057096==-- From publicity-bounces@lists.xenproject.org Thu May 14 10:21:21 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:21:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqGX-0006WQ-9l; Thu, 14 May 2015 10:21:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqGV-0006WI-P8 for publicity@lists.xenproject.org; Thu, 14 May 2015 10:21:19 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id 34/52-02789-E1774555; Thu, 14 May 2015 10:21:18 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1431598876!14947457!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30639 invoked from network); 14 May 2015 10:21:18 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 10:21:18 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="265009001" Date: Thu, 14 May 2015 11:20:47 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: "Lengyel, Tamas" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1342847746-591185117-1431598853=:20496" X-DLP: MIA2 Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --1342847746-591185117-1431598853=:20496 Content-Type: text/plain; charset="UTF-8" Content-Length: 4783 Content-Transfer-Encoding: quoted-printable I think it is good. I would also mention the possibility of running PV (and PVH) guests instead of HVM guests. On Wed, 13 May 2015, Lengyel, Tamas wrote: > Hi Everyone, > > I've put together a quick blog entry to remind people that using stubdomains can address issues with QEMU, like the new > VENOM vulnerability. Let me know if it would be appropriate for the Xen blog (or if you have any comments)! > > Thanks, > > Tamas > > > Hardening Xen against VENOM-style attacks > > > The recent disclosure of the VENOM bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating > in the tech news lately, causing many to reevaluate their security posture when using cloud infrastructures. That is a > very good thing indeed. Virtualization and the cloud has been for too long erroneously considered to be a silver bullet > against intrusions, malware and APTs. > > > The cloud is anything but a safe place. VENOM in that sense is just another one in the long list of vulnerabilities that > seem to be plaguing hypervisors. However, there are differences between vulnerabilities. While VENOM is indeed a serious > bug and can result in a VM escape, which can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fact, VENOM-style > attacks have been known for a long time. And there are easy-to-deploy counter-measures to mitigate the risk of such > exploits, natively available in Xen and KVM. > > > What is the root cause of VENOM=3F Emulation. > > > While modern systems come with a plethora of virtualization extensions, many components are still being emulated. The > biggest component of that are usually devices. Devices such as your network card, graphics card and your hard drive. While > Linux comes with paravirtual (virtualization-aware) drivers to create such devices, emulation is often the only solution > to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows. This > emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent > years. However, QEMU is not the only place where emulation is used within Xen. For a variety of interrupts and timers, > such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for performance and > scalability reasons. As with QEMU, this emulator has been just as exploitable. This is simply because emulating devices > and services is really complex and error-prone to program properly. > > > This fact, that emulation is complex and error-prone, has been known for a long time. Back in 2011, the Blackhat talk on > Virtunoid demonstrated such a VM escape attack against KVM, through QEMU. The author of Virtunoid even cautioned that > there will be many other bugs of that nature found by researchers. Fast-forward 4 years and we now have VENOM. > > > The good news is that there is an easy mitigation available for all present and future QEMU bugs, also mentioned in the > original Xen Security Advisory. It is called stubdomains. Stubdomains can nip the whole class of vulnerabilities exposed > by QEMU in the bud by moving QEMU into a deprivileged domain of its own. Instead of having QEMU run as root in dom0, a > stubdomain has access only to the VM it is providing emulation for. Thus, an escape through QEMU will only land an > attacker in a stubdomain, without access to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an > attacker would only have a very limited environment to run code in (as in return-to-libc/ROP-style), having exactly the > same level of privilege as in the domain where the attack started. Nothing to be gained for a lot of work, effectively > making the system as secure as it would be if only PV drivers were used. As a sidenote, KVM allows for similar jailing of > the QEMU process via the native SELinux sVirt policies. > > > One would think it is a complex process to take advantage of this protection, when it is, in fact, very simple. Add the > following line to your Xen domain configuration and you gain immediate protection against VENOM, and the whole class of > vulnerabilities brought to you by QEMU: > > device_model_stubdomain_override =3D 1 > > > Unfortunately, your cloud provider may not allow you to enable this option. They certainly should, so complain loudly and > repeatedly if that=E2=80=99s the case. There is no reason to keep this class of bugs alive. > > > > -- > > www.novetta.com > > Tamas K Lengyel > > Senior Security Researcher > > > 7921 Jones Branch Drive > > McLean VA 22102 > > Email =C2=A0tlengyel@novetta.com > > > --1342847746-591185117-1431598853=:20496 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --1342847746-591185117-1431598853=:20496-- From publicity-bounces@lists.xenproject.org Thu May 14 10:21:21 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:21:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqGX-0006WQ-9l; Thu, 14 May 2015 10:21:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqGV-0006WI-P8 for publicity@lists.xenproject.org; Thu, 14 May 2015 10:21:19 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id 34/52-02789-E1774555; Thu, 14 May 2015 10:21:18 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1431598876!14947457!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30639 invoked from network); 14 May 2015 10:21:18 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 10:21:18 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="265009001" Date: Thu, 14 May 2015 11:20:47 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: "Lengyel, Tamas" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1342847746-591185117-1431598853=:20496" X-DLP: MIA2 Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --1342847746-591185117-1431598853=:20496 Content-Type: text/plain; charset="UTF-8" Content-Length: 4783 Content-Transfer-Encoding: quoted-printable I think it is good. I would also mention the possibility of running PV (and PVH) guests instead of HVM guests. On Wed, 13 May 2015, Lengyel, Tamas wrote: > Hi Everyone, > > I've put together a quick blog entry to remind people that using stubdomains can address issues with QEMU, like the new > VENOM vulnerability. Let me know if it would be appropriate for the Xen blog (or if you have any comments)! > > Thanks, > > Tamas > > > Hardening Xen against VENOM-style attacks > > > The recent disclosure of the VENOM bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating > in the tech news lately, causing many to reevaluate their security posture when using cloud infrastructures. That is a > very good thing indeed. Virtualization and the cloud has been for too long erroneously considered to be a silver bullet > against intrusions, malware and APTs. > > > The cloud is anything but a safe place. VENOM in that sense is just another one in the long list of vulnerabilities that > seem to be plaguing hypervisors. However, there are differences between vulnerabilities. While VENOM is indeed a serious > bug and can result in a VM escape, which can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fact, VENOM-style > attacks have been known for a long time. And there are easy-to-deploy counter-measures to mitigate the risk of such > exploits, natively available in Xen and KVM. > > > What is the root cause of VENOM=3F Emulation. > > > While modern systems come with a plethora of virtualization extensions, many components are still being emulated. The > biggest component of that are usually devices. Devices such as your network card, graphics card and your hard drive. While > Linux comes with paravirtual (virtualization-aware) drivers to create such devices, emulation is often the only solution > to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows. This > emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent > years. However, QEMU is not the only place where emulation is used within Xen. For a variety of interrupts and timers, > such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for performance and > scalability reasons. As with QEMU, this emulator has been just as exploitable. This is simply because emulating devices > and services is really complex and error-prone to program properly. > > > This fact, that emulation is complex and error-prone, has been known for a long time. Back in 2011, the Blackhat talk on > Virtunoid demonstrated such a VM escape attack against KVM, through QEMU. The author of Virtunoid even cautioned that > there will be many other bugs of that nature found by researchers. Fast-forward 4 years and we now have VENOM. > > > The good news is that there is an easy mitigation available for all present and future QEMU bugs, also mentioned in the > original Xen Security Advisory. It is called stubdomains. Stubdomains can nip the whole class of vulnerabilities exposed > by QEMU in the bud by moving QEMU into a deprivileged domain of its own. Instead of having QEMU run as root in dom0, a > stubdomain has access only to the VM it is providing emulation for. Thus, an escape through QEMU will only land an > attacker in a stubdomain, without access to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an > attacker would only have a very limited environment to run code in (as in return-to-libc/ROP-style), having exactly the > same level of privilege as in the domain where the attack started. Nothing to be gained for a lot of work, effectively > making the system as secure as it would be if only PV drivers were used. As a sidenote, KVM allows for similar jailing of > the QEMU process via the native SELinux sVirt policies. > > > One would think it is a complex process to take advantage of this protection, when it is, in fact, very simple. Add the > following line to your Xen domain configuration and you gain immediate protection against VENOM, and the whole class of > vulnerabilities brought to you by QEMU: > > device_model_stubdomain_override =3D 1 > > > Unfortunately, your cloud provider may not allow you to enable this option. They certainly should, so complain loudly and > repeatedly if that=E2=80=99s the case. There is no reason to keep this class of bugs alive. > > > > -- > > www.novetta.com > > Tamas K Lengyel > > Senior Security Researcher > > > 7921 Jones Branch Drive > > McLean VA 22102 > > Email =C2=A0tlengyel@novetta.com > > > --1342847746-591185117-1431598853=:20496 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --1342847746-591185117-1431598853=:20496-- From publicity-bounces@lists.xenproject.org Thu May 14 10:39:24 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:39:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqXz-00080U-Qw; Thu, 14 May 2015 10:39:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqXy-00080A-CG for publicity@lists.xenproject.org; Thu, 14 May 2015 10:39:22 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 70/3E-03739-95B74555; Thu, 14 May 2015 10:39:21 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-206.messagelabs.com!1431599960!14920571!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17397 invoked from network); 14 May 2015 10:39:20 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 May 2015 10:39:20 -0000 Received: from flick.office (volstagg-0.srg.cl.cam.ac.uk [128.232.32.232]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0c18f2f2; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 14 May 2015 11:39:18 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 14 May 2015 11:39:20 +0100 Message-Id: References: To: Stefano Stabellini X-Mailer: Apple Mail (2.2098) Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org WWVhaC4uLiBpdCdzIHdvcnRoIG5vdGluZyB0aGF0IHVuaWtlcm5lbHMgbGlrZSBNaXJhZ2VPUyBv ciBIYUxWTSBuZXZlciB1c2UgdGhlIHg4NiBkZXZpY2UgZW11bGF0aW9uIGFuZCBzbyByZXF1aXJl IGEgZmFyIGVhc2llciB0byBhdWRpdCBoeXBlcnZpc29yIFRDQiB0aGF0IGRvZXNuJ3QgaW52b2x2 ZSBxZW11LgoKQWxzbywgaXMgaXQgd29ydGggbWVudGlvbmluZyB3aHkgdGhlIHFlbXUgc3R1YiBk b21haW4gaXNuJ3QgdGhlIGRlZmF1bHQ/ICBJcyBpdCBhbGwgY29tcGlsZWQgYW5kIGluc3RhbGxl ZCBpbiBtb3N0IG9mIHRoZSBoeXBlcnZpc29yIGRpc3RyaWJ1dGlvbnMgb24gVWJ1bnR1L0NlbnRP Uy9ldGM/ICBJIGRvbid0IHRoaW5rIGV2ZW4gWGVuU2VydmVyIHVzZXMgcWVtdSBzdHViIGRvbWFp bnMsIGFsdGhvdWdoIHRoYXQgbWlnaHQgaGF2ZSBjaGFuZ2VkIGluIHRoZSByZWNlbnQgcmVsZWFz ZS4KCi1hbmlsCgo+IE9uIDE0IE1heSAyMDE1LCBhdCAxMToyMCwgU3RlZmFubyBTdGFiZWxsaW5p IDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4gd3JvdGU6Cj4gCj4gSSB0aGluayBp dCBpcyBnb29kLiBJIHdvdWxkIGFsc28gbWVudGlvbiB0aGUgcG9zc2liaWxpdHkgb2YgcnVubmlu ZyBQVgo+IChhbmQgUFZIKSBndWVzdHMgaW5zdGVhZCBvZiBIVk0gZ3Vlc3RzLgo+IAo+IAo+IE9u IFdlZCwgMTMgTWF5IDIwMTUsIExlbmd5ZWwsIFRhbWFzIHdyb3RlOgo+PiBIaSBFdmVyeW9uZSwK Pj4gCj4+IEkndmUgcHV0IHRvZ2V0aGVyIGEgcXVpY2sgYmxvZyBlbnRyeSB0byByZW1pbmQgcGVv cGxlIHRoYXQgdXNpbmcgc3R1YmRvbWFpbnMgY2FuIGFkZHJlc3MgaXNzdWVzIHdpdGggUUVNVSwg bGlrZSB0aGUgbmV3Cj4+IFZFTk9NIHZ1bG5lcmFiaWxpdHkuIExldCBtZSBrbm93IGlmIGl0IHdv dWxkIGJlIGFwcHJvcHJpYXRlIGZvciB0aGUgWGVuIGJsb2cgKG9yIGlmIHlvdSBoYXZlIGFueSBj b21tZW50cykhCj4+IAo+PiBUaGFua3MsCj4+IAo+PiBUYW1hcwo+PiAKPj4gCj4+IEhhcmRlbmlu ZyBYZW4gYWdhaW5zdCBWRU5PTS1zdHlsZSBhdHRhY2tzCj4+IAo+PiAKPj4gVGhlIHJlY2VudCBk aXNjbG9zdXJlIG9mIHRoZSBWRU5PTSBidWcgYWZmZWN0aW5nIG1ham9yIG9wZW4tc291cmNlIGh5 cGVydmlzb3JzLCBzdWNoIGFzIEtWTSBhbmQgWGVuLCBoYXMgYmVlbiBjaXJjdWxhdGluZwo+PiBp biB0aGUgdGVjaCBuZXdzIGxhdGVseSwgY2F1c2luZyBtYW55IHRvIHJlZXZhbHVhdGUgdGhlaXIg c2VjdXJpdHkgcG9zdHVyZSB3aGVuIHVzaW5nIGNsb3VkIGluZnJhc3RydWN0dXJlcy4gVGhhdCBp cyBhCj4+IHZlcnkgZ29vZCB0aGluZyBpbmRlZWQuIFZpcnR1YWxpemF0aW9uIGFuZCB0aGUgY2xv dWQgaGFzIGJlZW4gZm9yIHRvbyBsb25nIGVycm9uZW91c2x5IGNvbnNpZGVyZWQgdG8gYmUgYSBz aWx2ZXIgYnVsbGV0Cj4+IGFnYWluc3QgaW50cnVzaW9ucywgbWFsd2FyZSBhbmQgQVBUcy4KPj4g Cj4+IAo+PiBUaGUgY2xvdWQgaXMgYW55dGhpbmcgYnV0IGEgc2FmZSBwbGFjZS4gVkVOT00gaW4g dGhhdCBzZW5zZSBpcyBqdXN0IGFub3RoZXIgb25lIGluIHRoZSBsb25nIGxpc3Qgb2YgdnVsbmVy YWJpbGl0aWVzIHRoYXQKPj4gc2VlbSB0byBiZSBwbGFndWluZyBoeXBlcnZpc29ycy4gSG93ZXZl ciwgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIGJldHdlZW4gdnVsbmVyYWJpbGl0aWVzLiBXaGlsZSBW RU5PTSBpcyBpbmRlZWQgYSBzZXJpb3VzCj4+IGJ1ZyBhbmQgY2FuIHJlc3VsdCBpbiBhIFZNIGVz Y2FwZSwgd2hpY2ggY2FuIGNvbXByb21pc2UgYWxsIFZNcyBvbiB0aGUgaG9zdCwgaXQgZG9lc27i gJl0IGhhdmUgdG8gYmUuIEluIGZhY3QsIFZFTk9NLXN0eWxlCj4+IGF0dGFja3MgaGF2ZSBiZWVu IGtub3duIGZvciBhIGxvbmcgdGltZS4gQW5kIHRoZXJlIGFyZSBlYXN5LXRvLWRlcGxveSBjb3Vu dGVyLW1lYXN1cmVzIHRvIG1pdGlnYXRlIHRoZSByaXNrIG9mIHN1Y2gKPj4gZXhwbG9pdHMsIG5h dGl2ZWx5IGF2YWlsYWJsZSBpbiBYZW4gYW5kIEtWTS4KPj4gCj4+IAo+PiBXaGF0IGlzIHRoZSBy b290IGNhdXNlIG9mIFZFTk9NPyBFbXVsYXRpb24uCj4+IAo+PiAKPj4gV2hpbGUgbW9kZXJuIHN5 c3RlbXMgY29tZSB3aXRoIGEgcGxldGhvcmEgb2YgdmlydHVhbGl6YXRpb24gZXh0ZW5zaW9ucywg bWFueSBjb21wb25lbnRzIGFyZSBzdGlsbCBiZWluZyBlbXVsYXRlZC4gVGhlCj4+IGJpZ2dlc3Qg Y29tcG9uZW50IG9mIHRoYXQgYXJlIHVzdWFsbHkgZGV2aWNlcy4gRGV2aWNlcyBzdWNoIGFzIHlv dXIgbmV0d29yayBjYXJkLCBncmFwaGljcyBjYXJkIGFuZCB5b3VyIGhhcmQgZHJpdmUuIFdoaWxl Cj4+IExpbnV4IGNvbWVzIHdpdGggcGFyYXZpcnR1YWwgKHZpcnR1YWxpemF0aW9uLWF3YXJlKSBk cml2ZXJzIHRvIGNyZWF0ZSBzdWNoIGRldmljZXMsIGVtdWxhdGlvbiBpcyBvZnRlbiB0aGUgb25s eSBzb2x1dGlvbgo+PiB0byBydW4gb3BlcmF0aW5nIHN5c3RlbXMgdGhhdCBkbyBub3QgaGF2ZSBz dWNoIGtlcm5lbCBkcml2ZXJzLiBUaGlzIGhhcyBiZWVuIHRyYWRpdGlvbmFsbHkgdGhlIGNhc2Ug d2l0aCBXaW5kb3dzLiBUaGlzCj4+IGVtdWxhdGlvbiBsYXllciBoYXMgYmVlbiBpbXBsZW1lbnRl ZCBpbiBRRU1VLCB3aGljaCBoYXMgY2F1c2VkIFZFTk9NIGFuZCBhIGhhbmRmdWwgb2Ygb3RoZXIg Vk0tZXNjYXBlIGJ1Z3MgaW4gcmVjZW50Cj4+IHllYXJzLiBIb3dldmVyLCBRRU1VIGlzIG5vdCB0 aGUgb25seSBwbGFjZSB3aGVyZSBlbXVsYXRpb24gaXMgdXNlZCB3aXRoaW4gWGVuLiBGb3IgYSB2 YXJpZXR5IG9mIGludGVycnVwdHMgYW5kIHRpbWVycywKPj4gc3VjaCBhcyBSVEMsIFBJVCwgSFBF VCwgUE1UaW1lciwgUElDLCBJT0FQSUMgYW5kIExBUElDLCB0aGVyZSBpcyBhIGJha2VkLWluIGVt dWxhdG9yIGluIFhlbiBpdHNlbGYgZm9yIHBlcmZvcm1hbmNlIGFuZAo+PiBzY2FsYWJpbGl0eSBy ZWFzb25zLiBBcyB3aXRoIFFFTVUsIHRoaXMgZW11bGF0b3IgaGFzIGJlZW4ganVzdCBhcyBleHBs b2l0YWJsZS4gVGhpcyBpcyBzaW1wbHkgYmVjYXVzZSBlbXVsYXRpbmcgZGV2aWNlcwo+PiBhbmQg c2VydmljZXMgaXMgcmVhbGx5IGNvbXBsZXggYW5kIGVycm9yLXByb25lIHRvIHByb2dyYW0gcHJv cGVybHkuCj4+IAo+PiAKPj4gVGhpcyBmYWN0LCB0aGF0IGVtdWxhdGlvbiBpcyBjb21wbGV4IGFu ZCBlcnJvci1wcm9uZSwgaGFzIGJlZW4ga25vd24gZm9yIGEgbG9uZyB0aW1lLiBCYWNrIGluIDIw MTEsIHRoZSBCbGFja2hhdCB0YWxrIG9uCj4+IFZpcnR1bm9pZCBkZW1vbnN0cmF0ZWQgc3VjaCBh IFZNIGVzY2FwZSBhdHRhY2sgYWdhaW5zdCBLVk0sIHRocm91Z2ggUUVNVS4gVGhlIGF1dGhvciBv ZiBWaXJ0dW5vaWQgZXZlbiBjYXV0aW9uZWQgdGhhdAo+PiB0aGVyZSB3aWxsIGJlIG1hbnkgb3Ro ZXIgYnVncyBvZiB0aGF0IG5hdHVyZSBmb3VuZCBieSByZXNlYXJjaGVycy4gRmFzdC1mb3J3YXJk IDQgeWVhcnMgYW5kIHdlIG5vdyBoYXZlIFZFTk9NLgo+PiAKPj4gCj4+IFRoZSBnb29kIG5ld3Mg aXMgdGhhdCB0aGVyZSBpcyBhbiBlYXN5IG1pdGlnYXRpb24gYXZhaWxhYmxlIGZvciBhbGwgcHJl c2VudCBhbmQgZnV0dXJlIFFFTVUgYnVncywgYWxzbyBtZW50aW9uZWQgaW4gdGhlCj4+IG9yaWdp bmFsIFhlbiBTZWN1cml0eSBBZHZpc29yeS4gSXQgaXMgY2FsbGVkIHN0dWJkb21haW5zLiBTdHVi ZG9tYWlucyBjYW4gbmlwIHRoZSB3aG9sZSBjbGFzcyBvZiB2dWxuZXJhYmlsaXRpZXMgZXhwb3Nl ZAo+PiBieSBRRU1VIGluIHRoZSBidWQgYnkgbW92aW5nIFFFTVUgaW50byBhIGRlcHJpdmlsZWdl ZCBkb21haW4gb2YgaXRzIG93bi4gSW5zdGVhZCBvZiBoYXZpbmcgUUVNVSBydW4gYXMgcm9vdCBp biBkb20wLCBhCj4+IHN0dWJkb21haW4gaGFzIGFjY2VzcyBvbmx5IHRvIHRoZSBWTSBpdCBpcyBw cm92aWRpbmcgZW11bGF0aW9uIGZvci4gVGh1cywgYW4gZXNjYXBlIHRocm91Z2ggUUVNVSB3aWxs IG9ubHkgbGFuZCBhbgo+PiBhdHRhY2tlciBpbiBhIHN0dWJkb21haW4sIHdpdGhvdXQgYWNjZXNz IHRvIGNyaXRpY2FsIHJlc291cmNlcy4gRnVydGhlcm1vcmUsIFFFTVUgaW4gYSBzdHViZG9tYWlu IHJ1bnMgb24gTWluaU9TLCB0aHVzIGFuCj4+IGF0dGFja2VyIHdvdWxkIG9ubHkgaGF2ZSBhIHZl cnkgbGltaXRlZCBlbnZpcm9ubWVudCB0byBydW4gY29kZSBpbiAoYXMgaW4gcmV0dXJuLXRvLWxp YmMvUk9QLXN0eWxlKSwgaGF2aW5nIGV4YWN0bHkgdGhlCj4+IHNhbWUgbGV2ZWwgb2YgcHJpdmls ZWdlIGFzIGluIHRoZSBkb21haW4gd2hlcmUgdGhlIGF0dGFjayBzdGFydGVkLiBOb3RoaW5nIHRv IGJlIGdhaW5lZCBmb3IgYSBsb3Qgb2Ygd29yaywgZWZmZWN0aXZlbHkKPj4gbWFraW5nIHRoZSBz eXN0ZW0gYXMgc2VjdXJlIGFzIGl0IHdvdWxkIGJlIGlmIG9ubHkgUFYgZHJpdmVycyB3ZXJlIHVz ZWQuIEFzIGEgc2lkZW5vdGUsIEtWTSBhbGxvd3MgZm9yIHNpbWlsYXIgamFpbGluZyBvZgo+PiB0 aGUgUUVNVSBwcm9jZXNzIHZpYSB0aGUgbmF0aXZlIFNFTGludXggc1ZpcnQgcG9saWNpZXMuCj4+ IAo+PiAKPj4gT25lIHdvdWxkIHRoaW5rIGl0IGlzIGEgY29tcGxleCBwcm9jZXNzIHRvIHRha2Ug YWR2YW50YWdlIG9mIHRoaXMgcHJvdGVjdGlvbiwgd2hlbiBpdCBpcywgaW4gZmFjdCwgdmVyeSBz aW1wbGUuIEFkZCB0aGUKPj4gZm9sbG93aW5nIGxpbmUgdG8geW91ciBYZW4gZG9tYWluIGNvbmZp Z3VyYXRpb24gYW5kIHlvdSBnYWluIGltbWVkaWF0ZSBwcm90ZWN0aW9uIGFnYWluc3QgVkVOT00s IGFuZCB0aGUgd2hvbGUgY2xhc3Mgb2YKPj4gdnVsbmVyYWJpbGl0aWVzIGJyb3VnaHQgdG8geW91 IGJ5IFFFTVU6Cj4+IAo+PiAgZGV2aWNlX21vZGVsX3N0dWJkb21haW5fb3ZlcnJpZGUgPSAxCj4+ IAo+PiAKPj4gVW5mb3J0dW5hdGVseSwgeW91ciBjbG91ZCBwcm92aWRlciBtYXkgbm90IGFsbG93 IHlvdSB0byBlbmFibGUgdGhpcyBvcHRpb24uIFRoZXkgY2VydGFpbmx5IHNob3VsZCwgc28gY29t cGxhaW4gbG91ZGx5IGFuZAo+PiByZXBlYXRlZGx5IGlmIHRoYXTigJlzIHRoZSBjYXNlLiBUaGVy ZSBpcyBubyByZWFzb24gdG8ga2VlcCB0aGlzIGNsYXNzIG9mIGJ1Z3MgYWxpdmUuCj4+IAo+PiAK Pj4gCj4+IC0tCj4+IAo+PiB3d3cubm92ZXR0YS5jb20KPj4gCj4+IFRhbWFzIEsgTGVuZ3llbAo+ PiAKPj4gU2VuaW9yIFNlY3VyaXR5IFJlc2VhcmNoZXIKPj4gCj4+IAo+PiA3OTIxIEpvbmVzIEJy YW5jaCBEcml2ZQo+PiAKPj4gTWNMZWFuIFZBIDIyMTAyCj4+IAo+PiBFbWFpbCAgdGxlbmd5ZWxA bm92ZXR0YS5jb20KPj4gCj4+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gUHVibGljaXR5IG1haWxpbmcgbGlzdAo+IFB1YmxpY2l0eUBsaXN0cy54 ZW5wcm9qZWN0Lm9yZwo+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxt YW4vbGlzdGluZm8vcHVibGljaXR5CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KUHVibGljaXR5IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9wdWJsaWNpdHkK From publicity-bounces@lists.xenproject.org Thu May 14 10:39:24 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:39:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqXz-00080U-Qw; Thu, 14 May 2015 10:39:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqXy-00080A-CG for publicity@lists.xenproject.org; Thu, 14 May 2015 10:39:22 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 70/3E-03739-95B74555; Thu, 14 May 2015 10:39:21 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-4.tower-206.messagelabs.com!1431599960!14920571!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17397 invoked from network); 14 May 2015 10:39:20 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 May 2015 10:39:20 -0000 Received: from flick.office (volstagg-0.srg.cl.cam.ac.uk [128.232.32.232]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0c18f2f2; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 14 May 2015 11:39:18 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 14 May 2015 11:39:20 +0100 Message-Id: References: To: Stefano Stabellini X-Mailer: Apple Mail (2.2098) Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org WWVhaC4uLiBpdCdzIHdvcnRoIG5vdGluZyB0aGF0IHVuaWtlcm5lbHMgbGlrZSBNaXJhZ2VPUyBv ciBIYUxWTSBuZXZlciB1c2UgdGhlIHg4NiBkZXZpY2UgZW11bGF0aW9uIGFuZCBzbyByZXF1aXJl IGEgZmFyIGVhc2llciB0byBhdWRpdCBoeXBlcnZpc29yIFRDQiB0aGF0IGRvZXNuJ3QgaW52b2x2 ZSBxZW11LgoKQWxzbywgaXMgaXQgd29ydGggbWVudGlvbmluZyB3aHkgdGhlIHFlbXUgc3R1YiBk b21haW4gaXNuJ3QgdGhlIGRlZmF1bHQ/ICBJcyBpdCBhbGwgY29tcGlsZWQgYW5kIGluc3RhbGxl ZCBpbiBtb3N0IG9mIHRoZSBoeXBlcnZpc29yIGRpc3RyaWJ1dGlvbnMgb24gVWJ1bnR1L0NlbnRP Uy9ldGM/ICBJIGRvbid0IHRoaW5rIGV2ZW4gWGVuU2VydmVyIHVzZXMgcWVtdSBzdHViIGRvbWFp bnMsIGFsdGhvdWdoIHRoYXQgbWlnaHQgaGF2ZSBjaGFuZ2VkIGluIHRoZSByZWNlbnQgcmVsZWFz ZS4KCi1hbmlsCgo+IE9uIDE0IE1heSAyMDE1LCBhdCAxMToyMCwgU3RlZmFubyBTdGFiZWxsaW5p IDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT4gd3JvdGU6Cj4gCj4gSSB0aGluayBp dCBpcyBnb29kLiBJIHdvdWxkIGFsc28gbWVudGlvbiB0aGUgcG9zc2liaWxpdHkgb2YgcnVubmlu ZyBQVgo+IChhbmQgUFZIKSBndWVzdHMgaW5zdGVhZCBvZiBIVk0gZ3Vlc3RzLgo+IAo+IAo+IE9u IFdlZCwgMTMgTWF5IDIwMTUsIExlbmd5ZWwsIFRhbWFzIHdyb3RlOgo+PiBIaSBFdmVyeW9uZSwK Pj4gCj4+IEkndmUgcHV0IHRvZ2V0aGVyIGEgcXVpY2sgYmxvZyBlbnRyeSB0byByZW1pbmQgcGVv cGxlIHRoYXQgdXNpbmcgc3R1YmRvbWFpbnMgY2FuIGFkZHJlc3MgaXNzdWVzIHdpdGggUUVNVSwg bGlrZSB0aGUgbmV3Cj4+IFZFTk9NIHZ1bG5lcmFiaWxpdHkuIExldCBtZSBrbm93IGlmIGl0IHdv dWxkIGJlIGFwcHJvcHJpYXRlIGZvciB0aGUgWGVuIGJsb2cgKG9yIGlmIHlvdSBoYXZlIGFueSBj b21tZW50cykhCj4+IAo+PiBUaGFua3MsCj4+IAo+PiBUYW1hcwo+PiAKPj4gCj4+IEhhcmRlbmlu ZyBYZW4gYWdhaW5zdCBWRU5PTS1zdHlsZSBhdHRhY2tzCj4+IAo+PiAKPj4gVGhlIHJlY2VudCBk aXNjbG9zdXJlIG9mIHRoZSBWRU5PTSBidWcgYWZmZWN0aW5nIG1ham9yIG9wZW4tc291cmNlIGh5 cGVydmlzb3JzLCBzdWNoIGFzIEtWTSBhbmQgWGVuLCBoYXMgYmVlbiBjaXJjdWxhdGluZwo+PiBp biB0aGUgdGVjaCBuZXdzIGxhdGVseSwgY2F1c2luZyBtYW55IHRvIHJlZXZhbHVhdGUgdGhlaXIg c2VjdXJpdHkgcG9zdHVyZSB3aGVuIHVzaW5nIGNsb3VkIGluZnJhc3RydWN0dXJlcy4gVGhhdCBp cyBhCj4+IHZlcnkgZ29vZCB0aGluZyBpbmRlZWQuIFZpcnR1YWxpemF0aW9uIGFuZCB0aGUgY2xv dWQgaGFzIGJlZW4gZm9yIHRvbyBsb25nIGVycm9uZW91c2x5IGNvbnNpZGVyZWQgdG8gYmUgYSBz aWx2ZXIgYnVsbGV0Cj4+IGFnYWluc3QgaW50cnVzaW9ucywgbWFsd2FyZSBhbmQgQVBUcy4KPj4g Cj4+IAo+PiBUaGUgY2xvdWQgaXMgYW55dGhpbmcgYnV0IGEgc2FmZSBwbGFjZS4gVkVOT00gaW4g dGhhdCBzZW5zZSBpcyBqdXN0IGFub3RoZXIgb25lIGluIHRoZSBsb25nIGxpc3Qgb2YgdnVsbmVy YWJpbGl0aWVzIHRoYXQKPj4gc2VlbSB0byBiZSBwbGFndWluZyBoeXBlcnZpc29ycy4gSG93ZXZl ciwgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIGJldHdlZW4gdnVsbmVyYWJpbGl0aWVzLiBXaGlsZSBW RU5PTSBpcyBpbmRlZWQgYSBzZXJpb3VzCj4+IGJ1ZyBhbmQgY2FuIHJlc3VsdCBpbiBhIFZNIGVz Y2FwZSwgd2hpY2ggY2FuIGNvbXByb21pc2UgYWxsIFZNcyBvbiB0aGUgaG9zdCwgaXQgZG9lc27i gJl0IGhhdmUgdG8gYmUuIEluIGZhY3QsIFZFTk9NLXN0eWxlCj4+IGF0dGFja3MgaGF2ZSBiZWVu IGtub3duIGZvciBhIGxvbmcgdGltZS4gQW5kIHRoZXJlIGFyZSBlYXN5LXRvLWRlcGxveSBjb3Vu dGVyLW1lYXN1cmVzIHRvIG1pdGlnYXRlIHRoZSByaXNrIG9mIHN1Y2gKPj4gZXhwbG9pdHMsIG5h dGl2ZWx5IGF2YWlsYWJsZSBpbiBYZW4gYW5kIEtWTS4KPj4gCj4+IAo+PiBXaGF0IGlzIHRoZSBy b290IGNhdXNlIG9mIFZFTk9NPyBFbXVsYXRpb24uCj4+IAo+PiAKPj4gV2hpbGUgbW9kZXJuIHN5 c3RlbXMgY29tZSB3aXRoIGEgcGxldGhvcmEgb2YgdmlydHVhbGl6YXRpb24gZXh0ZW5zaW9ucywg bWFueSBjb21wb25lbnRzIGFyZSBzdGlsbCBiZWluZyBlbXVsYXRlZC4gVGhlCj4+IGJpZ2dlc3Qg Y29tcG9uZW50IG9mIHRoYXQgYXJlIHVzdWFsbHkgZGV2aWNlcy4gRGV2aWNlcyBzdWNoIGFzIHlv dXIgbmV0d29yayBjYXJkLCBncmFwaGljcyBjYXJkIGFuZCB5b3VyIGhhcmQgZHJpdmUuIFdoaWxl Cj4+IExpbnV4IGNvbWVzIHdpdGggcGFyYXZpcnR1YWwgKHZpcnR1YWxpemF0aW9uLWF3YXJlKSBk cml2ZXJzIHRvIGNyZWF0ZSBzdWNoIGRldmljZXMsIGVtdWxhdGlvbiBpcyBvZnRlbiB0aGUgb25s eSBzb2x1dGlvbgo+PiB0byBydW4gb3BlcmF0aW5nIHN5c3RlbXMgdGhhdCBkbyBub3QgaGF2ZSBz dWNoIGtlcm5lbCBkcml2ZXJzLiBUaGlzIGhhcyBiZWVuIHRyYWRpdGlvbmFsbHkgdGhlIGNhc2Ug d2l0aCBXaW5kb3dzLiBUaGlzCj4+IGVtdWxhdGlvbiBsYXllciBoYXMgYmVlbiBpbXBsZW1lbnRl ZCBpbiBRRU1VLCB3aGljaCBoYXMgY2F1c2VkIFZFTk9NIGFuZCBhIGhhbmRmdWwgb2Ygb3RoZXIg Vk0tZXNjYXBlIGJ1Z3MgaW4gcmVjZW50Cj4+IHllYXJzLiBIb3dldmVyLCBRRU1VIGlzIG5vdCB0 aGUgb25seSBwbGFjZSB3aGVyZSBlbXVsYXRpb24gaXMgdXNlZCB3aXRoaW4gWGVuLiBGb3IgYSB2 YXJpZXR5IG9mIGludGVycnVwdHMgYW5kIHRpbWVycywKPj4gc3VjaCBhcyBSVEMsIFBJVCwgSFBF VCwgUE1UaW1lciwgUElDLCBJT0FQSUMgYW5kIExBUElDLCB0aGVyZSBpcyBhIGJha2VkLWluIGVt dWxhdG9yIGluIFhlbiBpdHNlbGYgZm9yIHBlcmZvcm1hbmNlIGFuZAo+PiBzY2FsYWJpbGl0eSBy ZWFzb25zLiBBcyB3aXRoIFFFTVUsIHRoaXMgZW11bGF0b3IgaGFzIGJlZW4ganVzdCBhcyBleHBs b2l0YWJsZS4gVGhpcyBpcyBzaW1wbHkgYmVjYXVzZSBlbXVsYXRpbmcgZGV2aWNlcwo+PiBhbmQg c2VydmljZXMgaXMgcmVhbGx5IGNvbXBsZXggYW5kIGVycm9yLXByb25lIHRvIHByb2dyYW0gcHJv cGVybHkuCj4+IAo+PiAKPj4gVGhpcyBmYWN0LCB0aGF0IGVtdWxhdGlvbiBpcyBjb21wbGV4IGFu ZCBlcnJvci1wcm9uZSwgaGFzIGJlZW4ga25vd24gZm9yIGEgbG9uZyB0aW1lLiBCYWNrIGluIDIw MTEsIHRoZSBCbGFja2hhdCB0YWxrIG9uCj4+IFZpcnR1bm9pZCBkZW1vbnN0cmF0ZWQgc3VjaCBh IFZNIGVzY2FwZSBhdHRhY2sgYWdhaW5zdCBLVk0sIHRocm91Z2ggUUVNVS4gVGhlIGF1dGhvciBv ZiBWaXJ0dW5vaWQgZXZlbiBjYXV0aW9uZWQgdGhhdAo+PiB0aGVyZSB3aWxsIGJlIG1hbnkgb3Ro ZXIgYnVncyBvZiB0aGF0IG5hdHVyZSBmb3VuZCBieSByZXNlYXJjaGVycy4gRmFzdC1mb3J3YXJk IDQgeWVhcnMgYW5kIHdlIG5vdyBoYXZlIFZFTk9NLgo+PiAKPj4gCj4+IFRoZSBnb29kIG5ld3Mg aXMgdGhhdCB0aGVyZSBpcyBhbiBlYXN5IG1pdGlnYXRpb24gYXZhaWxhYmxlIGZvciBhbGwgcHJl c2VudCBhbmQgZnV0dXJlIFFFTVUgYnVncywgYWxzbyBtZW50aW9uZWQgaW4gdGhlCj4+IG9yaWdp bmFsIFhlbiBTZWN1cml0eSBBZHZpc29yeS4gSXQgaXMgY2FsbGVkIHN0dWJkb21haW5zLiBTdHVi ZG9tYWlucyBjYW4gbmlwIHRoZSB3aG9sZSBjbGFzcyBvZiB2dWxuZXJhYmlsaXRpZXMgZXhwb3Nl ZAo+PiBieSBRRU1VIGluIHRoZSBidWQgYnkgbW92aW5nIFFFTVUgaW50byBhIGRlcHJpdmlsZWdl ZCBkb21haW4gb2YgaXRzIG93bi4gSW5zdGVhZCBvZiBoYXZpbmcgUUVNVSBydW4gYXMgcm9vdCBp biBkb20wLCBhCj4+IHN0dWJkb21haW4gaGFzIGFjY2VzcyBvbmx5IHRvIHRoZSBWTSBpdCBpcyBw cm92aWRpbmcgZW11bGF0aW9uIGZvci4gVGh1cywgYW4gZXNjYXBlIHRocm91Z2ggUUVNVSB3aWxs IG9ubHkgbGFuZCBhbgo+PiBhdHRhY2tlciBpbiBhIHN0dWJkb21haW4sIHdpdGhvdXQgYWNjZXNz IHRvIGNyaXRpY2FsIHJlc291cmNlcy4gRnVydGhlcm1vcmUsIFFFTVUgaW4gYSBzdHViZG9tYWlu IHJ1bnMgb24gTWluaU9TLCB0aHVzIGFuCj4+IGF0dGFja2VyIHdvdWxkIG9ubHkgaGF2ZSBhIHZl cnkgbGltaXRlZCBlbnZpcm9ubWVudCB0byBydW4gY29kZSBpbiAoYXMgaW4gcmV0dXJuLXRvLWxp YmMvUk9QLXN0eWxlKSwgaGF2aW5nIGV4YWN0bHkgdGhlCj4+IHNhbWUgbGV2ZWwgb2YgcHJpdmls ZWdlIGFzIGluIHRoZSBkb21haW4gd2hlcmUgdGhlIGF0dGFjayBzdGFydGVkLiBOb3RoaW5nIHRv IGJlIGdhaW5lZCBmb3IgYSBsb3Qgb2Ygd29yaywgZWZmZWN0aXZlbHkKPj4gbWFraW5nIHRoZSBz eXN0ZW0gYXMgc2VjdXJlIGFzIGl0IHdvdWxkIGJlIGlmIG9ubHkgUFYgZHJpdmVycyB3ZXJlIHVz ZWQuIEFzIGEgc2lkZW5vdGUsIEtWTSBhbGxvd3MgZm9yIHNpbWlsYXIgamFpbGluZyBvZgo+PiB0 aGUgUUVNVSBwcm9jZXNzIHZpYSB0aGUgbmF0aXZlIFNFTGludXggc1ZpcnQgcG9saWNpZXMuCj4+ IAo+PiAKPj4gT25lIHdvdWxkIHRoaW5rIGl0IGlzIGEgY29tcGxleCBwcm9jZXNzIHRvIHRha2Ug YWR2YW50YWdlIG9mIHRoaXMgcHJvdGVjdGlvbiwgd2hlbiBpdCBpcywgaW4gZmFjdCwgdmVyeSBz aW1wbGUuIEFkZCB0aGUKPj4gZm9sbG93aW5nIGxpbmUgdG8geW91ciBYZW4gZG9tYWluIGNvbmZp Z3VyYXRpb24gYW5kIHlvdSBnYWluIGltbWVkaWF0ZSBwcm90ZWN0aW9uIGFnYWluc3QgVkVOT00s IGFuZCB0aGUgd2hvbGUgY2xhc3Mgb2YKPj4gdnVsbmVyYWJpbGl0aWVzIGJyb3VnaHQgdG8geW91 IGJ5IFFFTVU6Cj4+IAo+PiAgZGV2aWNlX21vZGVsX3N0dWJkb21haW5fb3ZlcnJpZGUgPSAxCj4+ IAo+PiAKPj4gVW5mb3J0dW5hdGVseSwgeW91ciBjbG91ZCBwcm92aWRlciBtYXkgbm90IGFsbG93 IHlvdSB0byBlbmFibGUgdGhpcyBvcHRpb24uIFRoZXkgY2VydGFpbmx5IHNob3VsZCwgc28gY29t cGxhaW4gbG91ZGx5IGFuZAo+PiByZXBlYXRlZGx5IGlmIHRoYXTigJlzIHRoZSBjYXNlLiBUaGVy ZSBpcyBubyByZWFzb24gdG8ga2VlcCB0aGlzIGNsYXNzIG9mIGJ1Z3MgYWxpdmUuCj4+IAo+PiAK Pj4gCj4+IC0tCj4+IAo+PiB3d3cubm92ZXR0YS5jb20KPj4gCj4+IFRhbWFzIEsgTGVuZ3llbAo+ PiAKPj4gU2VuaW9yIFNlY3VyaXR5IFJlc2VhcmNoZXIKPj4gCj4+IAo+PiA3OTIxIEpvbmVzIEJy YW5jaCBEcml2ZQo+PiAKPj4gTWNMZWFuIFZBIDIyMTAyCj4+IAo+PiBFbWFpbCAgdGxlbmd5ZWxA bm92ZXR0YS5jb20KPj4gCj4+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gUHVibGljaXR5IG1haWxpbmcgbGlzdAo+IFB1YmxpY2l0eUBsaXN0cy54 ZW5wcm9qZWN0Lm9yZwo+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxt YW4vbGlzdGluZm8vcHVibGljaXR5CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KUHVibGljaXR5IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVu cHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9s aXN0aW5mby9wdWJsaWNpdHkK From publicity-bounces@lists.xenproject.org Thu May 14 10:55:16 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:55:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqnL-0001LR-Op; Thu, 14 May 2015 10:55:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqnL-0001LJ-01 for publicity@lists.xenproject.org; Thu, 14 May 2015 10:55:15 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 3B/FC-02776-11F74555; Thu, 14 May 2015 10:55:13 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1431600912!10918666!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23583 invoked from network); 14 May 2015 10:55:13 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 10:55:13 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="262617204" Message-ID: <55547EFA.8060504@eu.citrix.com> Date: Thu, 14 May 2015 11:54:50 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anil Madhavapeddy , Stefano Stabellini References: In-Reply-To: X-DLP: MIA1 Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. > > Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. Well the main reason is that qemu-upstream doesn't work with stub domains yet. Anthony worked on it for what, a year? He got pretty far but there are just a lot of thorny issues to deal with. -George _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 10:55:16 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:55:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqnL-0001LR-Op; Thu, 14 May 2015 10:55:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqnL-0001LJ-01 for publicity@lists.xenproject.org; Thu, 14 May 2015 10:55:15 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 3B/FC-02776-11F74555; Thu, 14 May 2015 10:55:13 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1431600912!10918666!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23583 invoked from network); 14 May 2015 10:55:13 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 10:55:13 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="262617204" Message-ID: <55547EFA.8060504@eu.citrix.com> Date: Thu, 14 May 2015 11:54:50 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anil Madhavapeddy , Stefano Stabellini References: In-Reply-To: X-DLP: MIA1 Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. > > Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. Well the main reason is that qemu-upstream doesn't work with stub domains yet. Anthony worked on it for what, a year? He got pretty far but there are just a lot of thorny issues to deal with. -George _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 10:58:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:58:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysqq3-0001Qn-0T; Thu, 14 May 2015 10:58:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysqq1-0001Qh-S0 for publicity@lists.xenproject.org; Thu, 14 May 2015 10:58:01 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 39/76-02824-8BF74555; Thu, 14 May 2015 10:58:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1431601079!14933912!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14248 invoked from network); 14 May 2015 10:58:00 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 10:58:00 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="262617571" Message-ID: <1431601057.13579.30.camel@citrix.com> From: Ian Campbell To: George Dunlap Date: Thu, 14 May 2015 11:57:37 +0100 In-Reply-To: <55547EFA.8060504@eu.citrix.com> References: <55547EFA.8060504@eu.citrix.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Thu, 2015-05-14 at 11:54 +0100, George Dunlap wrote: > On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > > Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. > > > > Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. > > Well the main reason is that qemu-upstream doesn't work with stub > domains yet. Anthony worked on it for what, a year? He got pretty far > but there are just a lot of thorny issues to deal with. AIUI Wei had something mostly working (at least the basics) with rumpkernels earlier this year. _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 10:58:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 10:58:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysqq3-0001Qn-0T; Thu, 14 May 2015 10:58:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysqq1-0001Qh-S0 for publicity@lists.xenproject.org; Thu, 14 May 2015 10:58:01 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 39/76-02824-8BF74555; Thu, 14 May 2015 10:58:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1431601079!14933912!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14248 invoked from network); 14 May 2015 10:58:00 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 10:58:00 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="262617571" Message-ID: <1431601057.13579.30.camel@citrix.com> From: Ian Campbell To: George Dunlap Date: Thu, 14 May 2015 11:57:37 +0100 In-Reply-To: <55547EFA.8060504@eu.citrix.com> References: <55547EFA.8060504@eu.citrix.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Thu, 2015-05-14 at 11:54 +0100, George Dunlap wrote: > On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > > Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. > > > > Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. > > Well the main reason is that qemu-upstream doesn't work with stub > domains yet. Anthony worked on it for what, a year? He got pretty far > but there are just a lot of thorny issues to deal with. AIUI Wei had something mostly working (at least the basics) with rumpkernels earlier this year. _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 11:00:37 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:00:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqsX-0001la-24; Thu, 14 May 2015 11:00:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqsV-0001lP-9m for publicity@lists.xenproject.org; Thu, 14 May 2015 11:00:35 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id B4/41-03206-25084555; Thu, 14 May 2015 11:00:34 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1431601232!11416591!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7781 invoked from network); 14 May 2015 11:00:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:00:33 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="265016643" Date: Thu, 14 May 2015 11:59:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: George Dunlap In-Reply-To: <55547EFA.8060504@eu.citrix.com> Message-ID: References: <55547EFA.8060504@eu.citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-DLP: MIA1 Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Thu, 14 May 2015, George Dunlap wrote: > On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > > Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. > > > > Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. > > Well the main reason is that qemu-upstream doesn't work with stub > domains yet. Anthony worked on it for what, a year? He got pretty far > but there are just a lot of thorny issues to deal with. To be fair, there are also other reasons: memory overhead, number of domains doubling, and the additional complexity of having 2 QEMUs for each domain (there is still one QEMU in Dom0 running for each guest, although it just provides the PV backends). _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 11:00:37 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:00:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqsX-0001la-24; Thu, 14 May 2015 11:00:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqsV-0001lP-9m for publicity@lists.xenproject.org; Thu, 14 May 2015 11:00:35 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id B4/41-03206-25084555; Thu, 14 May 2015 11:00:34 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1431601232!11416591!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7781 invoked from network); 14 May 2015 11:00:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:00:33 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="265016643" Date: Thu, 14 May 2015 11:59:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: George Dunlap In-Reply-To: <55547EFA.8060504@eu.citrix.com> Message-ID: References: <55547EFA.8060504@eu.citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-DLP: MIA1 Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On Thu, 14 May 2015, George Dunlap wrote: > On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > > Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. > > > > Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. > > Well the main reason is that qemu-upstream doesn't work with stub > domains yet. Anthony worked on it for what, a year? He got pretty far > but there are just a lot of thorny issues to deal with. To be fair, there are also other reasons: memory overhead, number of domains doubling, and the additional complexity of having 2 QEMUs for each domain (there is still one QEMU in Dom0 running for each guest, although it just provides the PV backends). _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 11:07:44 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:07:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqzP-0002Lt-UM; Thu, 14 May 2015 11:07:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqzO-0002Lj-N7 for publicity@lists.xenproject.org; Thu, 14 May 2015 11:07:42 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id B0/C6-03031-DF184555; Thu, 14 May 2015 11:07:41 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1431601660!17198061!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31554 invoked from network); 14 May 2015 11:07:40 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:07:40 -0000 Received: by wibt6 with SMTP id t6so10891098wib.0 for ; Thu, 14 May 2015 04:07:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CuslWo7rFnRXFYzijHLmHnlDyv5oHaC2j/vg5WDiltE=; b=A+fa6q2pWQI4jQczFzJvjvvl2X0GCMLRuw0N9sbyRRXRDn2wncSF2AtHEnBHZF0jX/ XFqyC78Kf6M9Wo38yo+a6TFGarfR8/nK+t8b/gq8veNPEh1aneixsxFQgjhUBZgupeTT wsHQFbXwfzYa6UNl5G7wkkshQUr1PdA6tjVNAGXLohHtiVlanri4T6yQzEQbxxdGczod jg+V4gqczgztLG8/3qau2qyu8iJpLiUPOCYfwhkh5EIs89UVhnQgDvOuft754xggrG76 urS7SeZULX7vn+ilgq81Z5RFJ75Woj04gjqx8V6oHcmASZDSvcUJprwmN3Lpffgw1sbu xKYQ== X-Gm-Message-State: ALoCoQnqTPFIuUqubNssJLprOxYbBy41j8Kky/xOq0pZxwzwq/isghDinfNWW+0N/ArXF7+/0Yox X-Received: by 10.180.219.42 with SMTP id pl10mr23231054wic.70.1431601660179; Thu, 14 May 2015 04:07:40 -0700 (PDT) Received: from [192.168.178.57] (ppp-188-174-126-183.dynamic.mnet-online.de. [188.174.126.183]) by mx.google.com with ESMTPSA id be6sm37606294wjb.14.2015.05.14.04.07.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 04:07:39 -0700 (PDT) Message-ID: <555481F9.2030504@novetta.com> Date: Thu, 14 May 2015 13:07:37 +0200 From: Tamas K Lengyel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stefano Stabellini , George Dunlap References: <55547EFA.8060504@eu.citrix.com> In-Reply-To: Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On 05/14/2015 12:59 PM, Stefano Stabellini wrote: > On Thu, 14 May 2015, George Dunlap wrote: >> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: >>> Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. >>> >>> Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. >> >> Well the main reason is that qemu-upstream doesn't work with stub >> domains yet. Anthony worked on it for what, a year? He got pretty far >> but there are just a lot of thorny issues to deal with. > > To be fair, there are also other reasons: memory overhead, number of > domains doubling, and the additional complexity of having 2 QEMUs for > each domain (there is still one QEMU in Dom0 running for each guest, > although it just provides the PV backends). > IMHO that's not necessarily a technical issue for not letting you use stubdoms. They could charge you for the extra domain same way as they charge you for your main VM. They would have to have dedicated hosts however where all domains use stubdoms, otherwise you don't become more protected - your neighbors do. Tamas _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 11:07:44 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:07:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqzP-0002Lt-UM; Thu, 14 May 2015 11:07:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsqzO-0002Lj-N7 for publicity@lists.xenproject.org; Thu, 14 May 2015 11:07:42 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id B0/C6-03031-DF184555; Thu, 14 May 2015 11:07:41 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1431601660!17198061!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31554 invoked from network); 14 May 2015 11:07:40 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:07:40 -0000 Received: by wibt6 with SMTP id t6so10891098wib.0 for ; Thu, 14 May 2015 04:07:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CuslWo7rFnRXFYzijHLmHnlDyv5oHaC2j/vg5WDiltE=; b=A+fa6q2pWQI4jQczFzJvjvvl2X0GCMLRuw0N9sbyRRXRDn2wncSF2AtHEnBHZF0jX/ XFqyC78Kf6M9Wo38yo+a6TFGarfR8/nK+t8b/gq8veNPEh1aneixsxFQgjhUBZgupeTT wsHQFbXwfzYa6UNl5G7wkkshQUr1PdA6tjVNAGXLohHtiVlanri4T6yQzEQbxxdGczod jg+V4gqczgztLG8/3qau2qyu8iJpLiUPOCYfwhkh5EIs89UVhnQgDvOuft754xggrG76 urS7SeZULX7vn+ilgq81Z5RFJ75Woj04gjqx8V6oHcmASZDSvcUJprwmN3Lpffgw1sbu xKYQ== X-Gm-Message-State: ALoCoQnqTPFIuUqubNssJLprOxYbBy41j8Kky/xOq0pZxwzwq/isghDinfNWW+0N/ArXF7+/0Yox X-Received: by 10.180.219.42 with SMTP id pl10mr23231054wic.70.1431601660179; Thu, 14 May 2015 04:07:40 -0700 (PDT) Received: from [192.168.178.57] (ppp-188-174-126-183.dynamic.mnet-online.de. [188.174.126.183]) by mx.google.com with ESMTPSA id be6sm37606294wjb.14.2015.05.14.04.07.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 04:07:39 -0700 (PDT) Message-ID: <555481F9.2030504@novetta.com> Date: Thu, 14 May 2015 13:07:37 +0200 From: Tamas K Lengyel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stefano Stabellini , George Dunlap References: <55547EFA.8060504@eu.citrix.com> In-Reply-To: Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On 05/14/2015 12:59 PM, Stefano Stabellini wrote: > On Thu, 14 May 2015, George Dunlap wrote: >> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: >>> Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. >>> >>> Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. >> >> Well the main reason is that qemu-upstream doesn't work with stub >> domains yet. Anthony worked on it for what, a year? He got pretty far >> but there are just a lot of thorny issues to deal with. > > To be fair, there are also other reasons: memory overhead, number of > domains doubling, and the additional complexity of having 2 QEMUs for > each domain (there is still one QEMU in Dom0 running for each guest, > although it just provides the PV backends). > IMHO that's not necessarily a technical issue for not letting you use stubdoms. They could charge you for the extra domain same way as they charge you for your main VM. They would have to have dedicated hosts however where all domains use stubdoms, otherwise you don't become more protected - your neighbors do. Tamas _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 11:08:37 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:08:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr0H-0002Pu-Ea; Thu, 14 May 2015 11:08:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr0F-0002Pj-Ts for publicity@lists.xenproject.org; Thu, 14 May 2015 11:08:36 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 84/CA-02788-23284555; Thu, 14 May 2015 11:08:34 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1431601713!17559397!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16368 invoked from network); 14 May 2015 11:08:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:08:34 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="142730" From: Paul Durrant To: Anil Madhavapeddy , Stefano Stabellini Thread-Topic: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks Thread-Index: AQHQjjJHiRcsDkXmakyH9ibMjPosjZ17T0aA Date: Thu, 14 May 2015 11:08:33 +0000 Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0258E4C62@AMSPEX01CL01.citrite.net> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-DLP: AMS1 Cc: "Lengyel, Tamas" , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBwdWJsaWNpdHktYm91bmNlc0Bs aXN0cy54ZW5wcm9qZWN0Lm9yZyBbbWFpbHRvOnB1YmxpY2l0eS0NCj4gYm91bmNlc0BsaXN0cy54 ZW5wcm9qZWN0Lm9yZ10gT24gQmVoYWxmIE9mIEFuaWwgTWFkaGF2YXBlZGR5DQo+IFNlbnQ6IDE0 IE1heSAyMDE1IDExOjM5DQo+IFRvOiBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gQ2M6IExlbmd5ZWws IFRhbWFzOyBwdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQ dWJsaWNpdHldIEJsb2ctcG9zdCBSRkM6IEhhcmRlbmluZyBYZW4gYWdhaW5zdCBWRU5PTS1zdHls ZQ0KPiBhdHRhY2tzDQo+IA0KPiBZZWFoLi4uIGl0J3Mgd29ydGggbm90aW5nIHRoYXQgdW5pa2Vy bmVscyBsaWtlIE1pcmFnZU9TIG9yIEhhTFZNIG5ldmVyIHVzZQ0KPiB0aGUgeDg2IGRldmljZSBl bXVsYXRpb24gYW5kIHNvIHJlcXVpcmUgYSBmYXIgZWFzaWVyIHRvIGF1ZGl0IGh5cGVydmlzb3Ig VENCDQo+IHRoYXQgZG9lc24ndCBpbnZvbHZlIHFlbXUuDQo+IA0KPiBBbHNvLCBpcyBpdCB3b3J0 aCBtZW50aW9uaW5nIHdoeSB0aGUgcWVtdSBzdHViIGRvbWFpbiBpc24ndCB0aGUgZGVmYXVsdD8g IElzIGl0DQo+IGFsbCBjb21waWxlZCBhbmQgaW5zdGFsbGVkIGluIG1vc3Qgb2YgdGhlIGh5cGVy dmlzb3IgZGlzdHJpYnV0aW9ucyBvbg0KPiBVYnVudHUvQ2VudE9TL2V0Yz8gIEkgZG9uJ3QgdGhp bmsgZXZlbiBYZW5TZXJ2ZXIgdXNlcyBxZW11IHN0dWIgZG9tYWlucywNCj4gYWx0aG91Z2ggdGhh dCBtaWdodCBoYXZlIGNoYW5nZWQgaW4gdGhlIHJlY2VudCByZWxlYXNlLg0KPiANCg0KTm8sIFhl blNlcnZlciBkb2VzIG5vdCB1c2Ugc3R1YiBkb21haW5zIG5vciBpcyB0aGVyZSBhIHBsYW4gdG8u IFVubGVzcyB0aGUgbWVtb3J5IGZvb3RwcmludCBvZiBhIHN0dWIgZG9tYWluIGNhbiBiZSBtYWRl IDw9IHRoZSBtZW1vcnkgZm9vdHByaW50IG9mIGEgcWVtdSBwcm9jZXNzLCB0aGUgaW1wYWN0IG9u IG91ciBzY2FsYWJpbGl0eSB3b3VsZCBwcmV2ZW50IHVzIGZyb20gZ29pbmcgaW4gdGhhdCBkaXJl Y3Rpb24uDQpUaGF0IHNhaWQsIHRoZXJlJ3Mgbm8gcmVhc29uIHdoeSBxZW11IHByb2Nlc3NlcyBu ZWVkIHRvIHJ1biBpbiBkb20wIGFuZCBJIHRoaW5rIFhlblNlcnZlciB3b3VsZCBlbWJyYWNlIHRo ZSBpZGVhIG9mIGEgcWVtdSBzZXJ2aWNlIGRvbWFpbi4NCg0KICBQYXVsDQoNCj4gLWFuaWwNCj4g DQo+ID4gT24gMTQgTWF5IDIwMTUsIGF0IDExOjIwLCBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHN0 ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPiB3cm90ZToNCj4gPg0KPiA+IEkgdGhpbmsg aXQgaXMgZ29vZC4gSSB3b3VsZCBhbHNvIG1lbnRpb24gdGhlIHBvc3NpYmlsaXR5IG9mIHJ1bm5p bmcgUFYNCj4gPiAoYW5kIFBWSCkgZ3Vlc3RzIGluc3RlYWQgb2YgSFZNIGd1ZXN0cy4NCj4gPg0K PiA+DQo+ID4gT24gV2VkLCAxMyBNYXkgMjAxNSwgTGVuZ3llbCwgVGFtYXMgd3JvdGU6DQo+ID4+ IEhpIEV2ZXJ5b25lLA0KPiA+Pg0KPiA+PiBJJ3ZlIHB1dCB0b2dldGhlciBhIHF1aWNrIGJsb2cg ZW50cnkgdG8gcmVtaW5kIHBlb3BsZSB0aGF0IHVzaW5nDQo+IHN0dWJkb21haW5zIGNhbiBhZGRy ZXNzIGlzc3VlcyB3aXRoIFFFTVUsIGxpa2UgdGhlIG5ldw0KPiA+PiBWRU5PTSB2dWxuZXJhYmls aXR5LiBMZXQgbWUga25vdyBpZiBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgdGhlIFhlbg0K PiBibG9nIChvciBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMpIQ0KPiA+Pg0KPiA+PiBUaGFua3Ms DQo+ID4+DQo+ID4+IFRhbWFzDQo+ID4+DQo+ID4+DQo+ID4+IEhhcmRlbmluZyBYZW4gYWdhaW5z dCBWRU5PTS1zdHlsZSBhdHRhY2tzDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSByZWNlbnQgZGlzY2xv c3VyZSBvZiB0aGUgVkVOT00gYnVnIGFmZmVjdGluZyBtYWpvciBvcGVuLXNvdXJjZQ0KPiBoeXBl cnZpc29ycywgc3VjaCBhcyBLVk0gYW5kIFhlbiwgaGFzIGJlZW4gY2lyY3VsYXRpbmcNCj4gPj4g aW4gdGhlIHRlY2ggbmV3cyBsYXRlbHksIGNhdXNpbmcgbWFueSB0byByZWV2YWx1YXRlIHRoZWly IHNlY3VyaXR5IHBvc3R1cmUNCj4gd2hlbiB1c2luZyBjbG91ZCBpbmZyYXN0cnVjdHVyZXMuIFRo YXQgaXMgYQ0KPiA+PiB2ZXJ5IGdvb2QgdGhpbmcgaW5kZWVkLiBWaXJ0dWFsaXphdGlvbiBhbmQg dGhlIGNsb3VkIGhhcyBiZWVuIGZvciB0b28gbG9uZw0KPiBlcnJvbmVvdXNseSBjb25zaWRlcmVk IHRvIGJlIGEgc2lsdmVyIGJ1bGxldA0KPiA+PiBhZ2FpbnN0IGludHJ1c2lvbnMsIG1hbHdhcmUg YW5kIEFQVHMuDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBjbG91ZCBpcyBhbnl0aGluZyBidXQgYSBz YWZlIHBsYWNlLiBWRU5PTSBpbiB0aGF0IHNlbnNlIGlzIGp1c3QNCj4gYW5vdGhlciBvbmUgaW4g dGhlIGxvbmcgbGlzdCBvZiB2dWxuZXJhYmlsaXRpZXMgdGhhdA0KPiA+PiBzZWVtIHRvIGJlIHBs YWd1aW5nIGh5cGVydmlzb3JzLiBIb3dldmVyLCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMNCj4gYmV0 d2VlbiB2dWxuZXJhYmlsaXRpZXMuIFdoaWxlIFZFTk9NIGlzIGluZGVlZCBhIHNlcmlvdXMNCj4g Pj4gYnVnIGFuZCBjYW4gcmVzdWx0IGluIGEgVk0gZXNjYXBlLCB3aGljaCBjYW4gY29tcHJvbWlz ZSBhbGwgVk1zIG9uIHRoZQ0KPiBob3N0LCBpdCBkb2VzbuKAmXQgaGF2ZSB0byBiZS4gSW4gZmFj dCwgVkVOT00tc3R5bGUNCj4gPj4gYXR0YWNrcyBoYXZlIGJlZW4ga25vd24gZm9yIGEgbG9uZyB0 aW1lLiBBbmQgdGhlcmUgYXJlIGVhc3ktdG8tZGVwbG95DQo+IGNvdW50ZXItbWVhc3VyZXMgdG8g bWl0aWdhdGUgdGhlIHJpc2sgb2Ygc3VjaA0KPiA+PiBleHBsb2l0cywgbmF0aXZlbHkgYXZhaWxh YmxlIGluIFhlbiBhbmQgS1ZNLg0KPiA+Pg0KPiA+Pg0KPiA+PiBXaGF0IGlzIHRoZSByb290IGNh dXNlIG9mIFZFTk9NPyBFbXVsYXRpb24uDQo+ID4+DQo+ID4+DQo+ID4+IFdoaWxlIG1vZGVybiBz eXN0ZW1zIGNvbWUgd2l0aCBhIHBsZXRob3JhIG9mIHZpcnR1YWxpemF0aW9uIGV4dGVuc2lvbnMs DQo+IG1hbnkgY29tcG9uZW50cyBhcmUgc3RpbGwgYmVpbmcgZW11bGF0ZWQuIFRoZQ0KPiA+PiBi aWdnZXN0IGNvbXBvbmVudCBvZiB0aGF0IGFyZSB1c3VhbGx5IGRldmljZXMuIERldmljZXMgc3Vj aCBhcyB5b3VyDQo+IG5ldHdvcmsgY2FyZCwgZ3JhcGhpY3MgY2FyZCBhbmQgeW91ciBoYXJkIGRy aXZlLiBXaGlsZQ0KPiA+PiBMaW51eCBjb21lcyB3aXRoIHBhcmF2aXJ0dWFsICh2aXJ0dWFsaXph dGlvbi1hd2FyZSkgZHJpdmVycyB0byBjcmVhdGUgc3VjaA0KPiBkZXZpY2VzLCBlbXVsYXRpb24g aXMgb2Z0ZW4gdGhlIG9ubHkgc29sdXRpb24NCj4gPj4gdG8gcnVuIG9wZXJhdGluZyBzeXN0ZW1z IHRoYXQgZG8gbm90IGhhdmUgc3VjaCBrZXJuZWwgZHJpdmVycy4gVGhpcyBoYXMNCj4gYmVlbiB0 cmFkaXRpb25hbGx5IHRoZSBjYXNlIHdpdGggV2luZG93cy4gVGhpcw0KPiA+PiBlbXVsYXRpb24g bGF5ZXIgaGFzIGJlZW4gaW1wbGVtZW50ZWQgaW4gUUVNVSwgd2hpY2ggaGFzIGNhdXNlZA0KPiBW RU5PTSBhbmQgYSBoYW5kZnVsIG9mIG90aGVyIFZNLWVzY2FwZSBidWdzIGluIHJlY2VudA0KPiA+ PiB5ZWFycy4gSG93ZXZlciwgUUVNVSBpcyBub3QgdGhlIG9ubHkgcGxhY2Ugd2hlcmUgZW11bGF0 aW9uIGlzIHVzZWQNCj4gd2l0aGluIFhlbi4gRm9yIGEgdmFyaWV0eSBvZiBpbnRlcnJ1cHRzIGFu ZCB0aW1lcnMsDQo+ID4+IHN1Y2ggYXMgUlRDLCBQSVQsIEhQRVQsIFBNVGltZXIsIFBJQywgSU9B UElDIGFuZCBMQVBJQywgdGhlcmUgaXMgYSBiYWtlZC0NCj4gaW4gZW11bGF0b3IgaW4gWGVuIGl0 c2VsZiBmb3IgcGVyZm9ybWFuY2UgYW5kDQo+ID4+IHNjYWxhYmlsaXR5IHJlYXNvbnMuIEFzIHdp dGggUUVNVSwgdGhpcyBlbXVsYXRvciBoYXMgYmVlbiBqdXN0IGFzDQo+IGV4cGxvaXRhYmxlLiBU aGlzIGlzIHNpbXBseSBiZWNhdXNlIGVtdWxhdGluZyBkZXZpY2VzDQo+ID4+IGFuZCBzZXJ2aWNl cyBpcyByZWFsbHkgY29tcGxleCBhbmQgZXJyb3ItcHJvbmUgdG8gcHJvZ3JhbSBwcm9wZXJseS4N Cj4gPj4NCj4gPj4NCj4gPj4gVGhpcyBmYWN0LCB0aGF0IGVtdWxhdGlvbiBpcyBjb21wbGV4IGFu ZCBlcnJvci1wcm9uZSwgaGFzIGJlZW4ga25vd24gZm9yDQo+IGEgbG9uZyB0aW1lLiBCYWNrIGlu IDIwMTEsIHRoZSBCbGFja2hhdCB0YWxrIG9uDQo+ID4+IFZpcnR1bm9pZCBkZW1vbnN0cmF0ZWQg c3VjaCBhIFZNIGVzY2FwZSBhdHRhY2sgYWdhaW5zdCBLVk0sIHRocm91Z2gNCj4gUUVNVS4gVGhl IGF1dGhvciBvZiBWaXJ0dW5vaWQgZXZlbiBjYXV0aW9uZWQgdGhhdA0KPiA+PiB0aGVyZSB3aWxs IGJlIG1hbnkgb3RoZXIgYnVncyBvZiB0aGF0IG5hdHVyZSBmb3VuZCBieSByZXNlYXJjaGVycy4g RmFzdC0NCj4gZm9yd2FyZCA0IHllYXJzIGFuZCB3ZSBub3cgaGF2ZSBWRU5PTS4NCj4gPj4NCj4g Pj4NCj4gPj4gVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHRoZXJlIGlzIGFuIGVhc3kgbWl0aWdhdGlv biBhdmFpbGFibGUgZm9yIGFsbCBwcmVzZW50DQo+IGFuZCBmdXR1cmUgUUVNVSBidWdzLCBhbHNv IG1lbnRpb25lZCBpbiB0aGUNCj4gPj4gb3JpZ2luYWwgWGVuIFNlY3VyaXR5IEFkdmlzb3J5LiBJ dCBpcyBjYWxsZWQgc3R1YmRvbWFpbnMuIFN0dWJkb21haW5zIGNhbg0KPiBuaXAgdGhlIHdob2xl IGNsYXNzIG9mIHZ1bG5lcmFiaWxpdGllcyBleHBvc2VkDQo+ID4+IGJ5IFFFTVUgaW4gdGhlIGJ1 ZCBieSBtb3ZpbmcgUUVNVSBpbnRvIGEgZGVwcml2aWxlZ2VkIGRvbWFpbiBvZiBpdHMNCj4gb3du LiBJbnN0ZWFkIG9mIGhhdmluZyBRRU1VIHJ1biBhcyByb290IGluIGRvbTAsIGENCj4gPj4gc3R1 YmRvbWFpbiBoYXMgYWNjZXNzIG9ubHkgdG8gdGhlIFZNIGl0IGlzIHByb3ZpZGluZyBlbXVsYXRp b24gZm9yLiBUaHVzLA0KPiBhbiBlc2NhcGUgdGhyb3VnaCBRRU1VIHdpbGwgb25seSBsYW5kIGFu DQo+ID4+IGF0dGFja2VyIGluIGEgc3R1YmRvbWFpbiwgd2l0aG91dCBhY2Nlc3MgdG8gY3JpdGlj YWwgcmVzb3VyY2VzLg0KPiBGdXJ0aGVybW9yZSwgUUVNVSBpbiBhIHN0dWJkb21haW4gcnVucyBv biBNaW5pT1MsIHRodXMgYW4NCj4gPj4gYXR0YWNrZXIgd291bGQgb25seSBoYXZlIGEgdmVyeSBs aW1pdGVkIGVudmlyb25tZW50IHRvIHJ1biBjb2RlIGluIChhcyBpbg0KPiByZXR1cm4tdG8tbGli Yy9ST1Atc3R5bGUpLCBoYXZpbmcgZXhhY3RseSB0aGUNCj4gPj4gc2FtZSBsZXZlbCBvZiBwcml2 aWxlZ2UgYXMgaW4gdGhlIGRvbWFpbiB3aGVyZSB0aGUgYXR0YWNrIHN0YXJ0ZWQuIE5vdGhpbmcN Cj4gdG8gYmUgZ2FpbmVkIGZvciBhIGxvdCBvZiB3b3JrLCBlZmZlY3RpdmVseQ0KPiA+PiBtYWtp bmcgdGhlIHN5c3RlbSBhcyBzZWN1cmUgYXMgaXQgd291bGQgYmUgaWYgb25seSBQViBkcml2ZXJz IHdlcmUgdXNlZC4NCj4gQXMgYSBzaWRlbm90ZSwgS1ZNIGFsbG93cyBmb3Igc2ltaWxhciBqYWls aW5nIG9mDQo+ID4+IHRoZSBRRU1VIHByb2Nlc3MgdmlhIHRoZSBuYXRpdmUgU0VMaW51eCBzVmly dCBwb2xpY2llcy4NCj4gPj4NCj4gPj4NCj4gPj4gT25lIHdvdWxkIHRoaW5rIGl0IGlzIGEgY29t cGxleCBwcm9jZXNzIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoaXMNCj4gcHJvdGVjdGlvbiwgd2hl biBpdCBpcywgaW4gZmFjdCwgdmVyeSBzaW1wbGUuIEFkZCB0aGUNCj4gPj4gZm9sbG93aW5nIGxp bmUgdG8geW91ciBYZW4gZG9tYWluIGNvbmZpZ3VyYXRpb24gYW5kIHlvdSBnYWluIGltbWVkaWF0 ZQ0KPiBwcm90ZWN0aW9uIGFnYWluc3QgVkVOT00sIGFuZCB0aGUgd2hvbGUgY2xhc3Mgb2YNCj4g Pj4gdnVsbmVyYWJpbGl0aWVzIGJyb3VnaHQgdG8geW91IGJ5IFFFTVU6DQo+ID4+DQo+ID4+ICBk ZXZpY2VfbW9kZWxfc3R1YmRvbWFpbl9vdmVycmlkZSA9IDENCj4gPj4NCj4gPj4NCj4gPj4gVW5m b3J0dW5hdGVseSwgeW91ciBjbG91ZCBwcm92aWRlciBtYXkgbm90IGFsbG93IHlvdSB0byBlbmFi bGUgdGhpcw0KPiBvcHRpb24uIFRoZXkgY2VydGFpbmx5IHNob3VsZCwgc28gY29tcGxhaW4gbG91 ZGx5IGFuZA0KPiA+PiByZXBlYXRlZGx5IGlmIHRoYXTigJlzIHRoZSBjYXNlLiBUaGVyZSBpcyBu byByZWFzb24gdG8ga2VlcCB0aGlzIGNsYXNzIG9mIGJ1Z3MNCj4gYWxpdmUuDQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+ID4+IHd3dy5ub3ZldHRhLmNvbQ0KPiA+Pg0KPiA+PiBU YW1hcyBLIExlbmd5ZWwNCj4gPj4NCj4gPj4gU2VuaW9yIFNlY3VyaXR5IFJlc2VhcmNoZXINCj4g Pj4NCj4gPj4NCj4gPj4gNzkyMSBKb25lcyBCcmFuY2ggRHJpdmUNCj4gPj4NCj4gPj4gTWNMZWFu IFZBIDIyMTAyDQo+ID4+DQo+ID4+IEVtYWlsICB0bGVuZ3llbEBub3ZldHRhLmNvbQ0KPiA+Pg0K PiA+Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gUHVibGljaXR5IG1haWxpbmcgbGlzdA0KPiA+IFB1YmxpY2l0eUBsaXN0cy54ZW5wcm9q ZWN0Lm9yZw0KPiA+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4v bGlzdGluZm8vcHVibGljaXR5DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gUHVibGljaXR5IG1haWxpbmcgbGlzdA0KPiBQdWJsaWNp dHlAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2Nn aS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fClB1YmxpY2l0eSBtYWlsaW5nIGxpc3QKUHVibGljaXR5 QGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmlu L21haWxtYW4vbGlzdGluZm8vcHVibGljaXR5Cg== From publicity-bounces@lists.xenproject.org Thu May 14 11:08:37 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:08:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr0H-0002Pu-Ea; Thu, 14 May 2015 11:08:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr0F-0002Pj-Ts for publicity@lists.xenproject.org; Thu, 14 May 2015 11:08:36 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 84/CA-02788-23284555; Thu, 14 May 2015 11:08:34 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1431601713!17559397!1 X-Originating-IP: [185.25.65.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16368 invoked from network); 14 May 2015 11:08:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (185.25.65.24) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:08:34 -0000 X-IronPort-AV: E=Sophos;i="5.13,427,1427760000"; d="scan'208";a="142730" From: Paul Durrant To: Anil Madhavapeddy , Stefano Stabellini Thread-Topic: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks Thread-Index: AQHQjjJHiRcsDkXmakyH9ibMjPosjZ17T0aA Date: Thu, 14 May 2015 11:08:33 +0000 Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0258E4C62@AMSPEX01CL01.citrite.net> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-DLP: AMS1 Cc: "Lengyel, Tamas" , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBwdWJsaWNpdHktYm91bmNlc0Bs aXN0cy54ZW5wcm9qZWN0Lm9yZyBbbWFpbHRvOnB1YmxpY2l0eS0NCj4gYm91bmNlc0BsaXN0cy54 ZW5wcm9qZWN0Lm9yZ10gT24gQmVoYWxmIE9mIEFuaWwgTWFkaGF2YXBlZGR5DQo+IFNlbnQ6IDE0 IE1heSAyMDE1IDExOjM5DQo+IFRvOiBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gQ2M6IExlbmd5ZWws IFRhbWFzOyBwdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQ dWJsaWNpdHldIEJsb2ctcG9zdCBSRkM6IEhhcmRlbmluZyBYZW4gYWdhaW5zdCBWRU5PTS1zdHls ZQ0KPiBhdHRhY2tzDQo+IA0KPiBZZWFoLi4uIGl0J3Mgd29ydGggbm90aW5nIHRoYXQgdW5pa2Vy bmVscyBsaWtlIE1pcmFnZU9TIG9yIEhhTFZNIG5ldmVyIHVzZQ0KPiB0aGUgeDg2IGRldmljZSBl bXVsYXRpb24gYW5kIHNvIHJlcXVpcmUgYSBmYXIgZWFzaWVyIHRvIGF1ZGl0IGh5cGVydmlzb3Ig VENCDQo+IHRoYXQgZG9lc24ndCBpbnZvbHZlIHFlbXUuDQo+IA0KPiBBbHNvLCBpcyBpdCB3b3J0 aCBtZW50aW9uaW5nIHdoeSB0aGUgcWVtdSBzdHViIGRvbWFpbiBpc24ndCB0aGUgZGVmYXVsdD8g IElzIGl0DQo+IGFsbCBjb21waWxlZCBhbmQgaW5zdGFsbGVkIGluIG1vc3Qgb2YgdGhlIGh5cGVy dmlzb3IgZGlzdHJpYnV0aW9ucyBvbg0KPiBVYnVudHUvQ2VudE9TL2V0Yz8gIEkgZG9uJ3QgdGhp bmsgZXZlbiBYZW5TZXJ2ZXIgdXNlcyBxZW11IHN0dWIgZG9tYWlucywNCj4gYWx0aG91Z2ggdGhh dCBtaWdodCBoYXZlIGNoYW5nZWQgaW4gdGhlIHJlY2VudCByZWxlYXNlLg0KPiANCg0KTm8sIFhl blNlcnZlciBkb2VzIG5vdCB1c2Ugc3R1YiBkb21haW5zIG5vciBpcyB0aGVyZSBhIHBsYW4gdG8u IFVubGVzcyB0aGUgbWVtb3J5IGZvb3RwcmludCBvZiBhIHN0dWIgZG9tYWluIGNhbiBiZSBtYWRl IDw9IHRoZSBtZW1vcnkgZm9vdHByaW50IG9mIGEgcWVtdSBwcm9jZXNzLCB0aGUgaW1wYWN0IG9u IG91ciBzY2FsYWJpbGl0eSB3b3VsZCBwcmV2ZW50IHVzIGZyb20gZ29pbmcgaW4gdGhhdCBkaXJl Y3Rpb24uDQpUaGF0IHNhaWQsIHRoZXJlJ3Mgbm8gcmVhc29uIHdoeSBxZW11IHByb2Nlc3NlcyBu ZWVkIHRvIHJ1biBpbiBkb20wIGFuZCBJIHRoaW5rIFhlblNlcnZlciB3b3VsZCBlbWJyYWNlIHRo ZSBpZGVhIG9mIGEgcWVtdSBzZXJ2aWNlIGRvbWFpbi4NCg0KICBQYXVsDQoNCj4gLWFuaWwNCj4g DQo+ID4gT24gMTQgTWF5IDIwMTUsIGF0IDExOjIwLCBTdGVmYW5vIFN0YWJlbGxpbmkNCj4gPHN0 ZWZhbm8uc3RhYmVsbGluaUBldS5jaXRyaXguY29tPiB3cm90ZToNCj4gPg0KPiA+IEkgdGhpbmsg aXQgaXMgZ29vZC4gSSB3b3VsZCBhbHNvIG1lbnRpb24gdGhlIHBvc3NpYmlsaXR5IG9mIHJ1bm5p bmcgUFYNCj4gPiAoYW5kIFBWSCkgZ3Vlc3RzIGluc3RlYWQgb2YgSFZNIGd1ZXN0cy4NCj4gPg0K PiA+DQo+ID4gT24gV2VkLCAxMyBNYXkgMjAxNSwgTGVuZ3llbCwgVGFtYXMgd3JvdGU6DQo+ID4+ IEhpIEV2ZXJ5b25lLA0KPiA+Pg0KPiA+PiBJJ3ZlIHB1dCB0b2dldGhlciBhIHF1aWNrIGJsb2cg ZW50cnkgdG8gcmVtaW5kIHBlb3BsZSB0aGF0IHVzaW5nDQo+IHN0dWJkb21haW5zIGNhbiBhZGRy ZXNzIGlzc3VlcyB3aXRoIFFFTVUsIGxpa2UgdGhlIG5ldw0KPiA+PiBWRU5PTSB2dWxuZXJhYmls aXR5LiBMZXQgbWUga25vdyBpZiBpdCB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgdGhlIFhlbg0K PiBibG9nIChvciBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMpIQ0KPiA+Pg0KPiA+PiBUaGFua3Ms DQo+ID4+DQo+ID4+IFRhbWFzDQo+ID4+DQo+ID4+DQo+ID4+IEhhcmRlbmluZyBYZW4gYWdhaW5z dCBWRU5PTS1zdHlsZSBhdHRhY2tzDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSByZWNlbnQgZGlzY2xv c3VyZSBvZiB0aGUgVkVOT00gYnVnIGFmZmVjdGluZyBtYWpvciBvcGVuLXNvdXJjZQ0KPiBoeXBl cnZpc29ycywgc3VjaCBhcyBLVk0gYW5kIFhlbiwgaGFzIGJlZW4gY2lyY3VsYXRpbmcNCj4gPj4g aW4gdGhlIHRlY2ggbmV3cyBsYXRlbHksIGNhdXNpbmcgbWFueSB0byByZWV2YWx1YXRlIHRoZWly IHNlY3VyaXR5IHBvc3R1cmUNCj4gd2hlbiB1c2luZyBjbG91ZCBpbmZyYXN0cnVjdHVyZXMuIFRo YXQgaXMgYQ0KPiA+PiB2ZXJ5IGdvb2QgdGhpbmcgaW5kZWVkLiBWaXJ0dWFsaXphdGlvbiBhbmQg dGhlIGNsb3VkIGhhcyBiZWVuIGZvciB0b28gbG9uZw0KPiBlcnJvbmVvdXNseSBjb25zaWRlcmVk IHRvIGJlIGEgc2lsdmVyIGJ1bGxldA0KPiA+PiBhZ2FpbnN0IGludHJ1c2lvbnMsIG1hbHdhcmUg YW5kIEFQVHMuDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBjbG91ZCBpcyBhbnl0aGluZyBidXQgYSBz YWZlIHBsYWNlLiBWRU5PTSBpbiB0aGF0IHNlbnNlIGlzIGp1c3QNCj4gYW5vdGhlciBvbmUgaW4g dGhlIGxvbmcgbGlzdCBvZiB2dWxuZXJhYmlsaXRpZXMgdGhhdA0KPiA+PiBzZWVtIHRvIGJlIHBs YWd1aW5nIGh5cGVydmlzb3JzLiBIb3dldmVyLCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMNCj4gYmV0 d2VlbiB2dWxuZXJhYmlsaXRpZXMuIFdoaWxlIFZFTk9NIGlzIGluZGVlZCBhIHNlcmlvdXMNCj4g Pj4gYnVnIGFuZCBjYW4gcmVzdWx0IGluIGEgVk0gZXNjYXBlLCB3aGljaCBjYW4gY29tcHJvbWlz ZSBhbGwgVk1zIG9uIHRoZQ0KPiBob3N0LCBpdCBkb2VzbuKAmXQgaGF2ZSB0byBiZS4gSW4gZmFj dCwgVkVOT00tc3R5bGUNCj4gPj4gYXR0YWNrcyBoYXZlIGJlZW4ga25vd24gZm9yIGEgbG9uZyB0 aW1lLiBBbmQgdGhlcmUgYXJlIGVhc3ktdG8tZGVwbG95DQo+IGNvdW50ZXItbWVhc3VyZXMgdG8g bWl0aWdhdGUgdGhlIHJpc2sgb2Ygc3VjaA0KPiA+PiBleHBsb2l0cywgbmF0aXZlbHkgYXZhaWxh YmxlIGluIFhlbiBhbmQgS1ZNLg0KPiA+Pg0KPiA+Pg0KPiA+PiBXaGF0IGlzIHRoZSByb290IGNh dXNlIG9mIFZFTk9NPyBFbXVsYXRpb24uDQo+ID4+DQo+ID4+DQo+ID4+IFdoaWxlIG1vZGVybiBz eXN0ZW1zIGNvbWUgd2l0aCBhIHBsZXRob3JhIG9mIHZpcnR1YWxpemF0aW9uIGV4dGVuc2lvbnMs DQo+IG1hbnkgY29tcG9uZW50cyBhcmUgc3RpbGwgYmVpbmcgZW11bGF0ZWQuIFRoZQ0KPiA+PiBi aWdnZXN0IGNvbXBvbmVudCBvZiB0aGF0IGFyZSB1c3VhbGx5IGRldmljZXMuIERldmljZXMgc3Vj aCBhcyB5b3VyDQo+IG5ldHdvcmsgY2FyZCwgZ3JhcGhpY3MgY2FyZCBhbmQgeW91ciBoYXJkIGRy aXZlLiBXaGlsZQ0KPiA+PiBMaW51eCBjb21lcyB3aXRoIHBhcmF2aXJ0dWFsICh2aXJ0dWFsaXph dGlvbi1hd2FyZSkgZHJpdmVycyB0byBjcmVhdGUgc3VjaA0KPiBkZXZpY2VzLCBlbXVsYXRpb24g aXMgb2Z0ZW4gdGhlIG9ubHkgc29sdXRpb24NCj4gPj4gdG8gcnVuIG9wZXJhdGluZyBzeXN0ZW1z IHRoYXQgZG8gbm90IGhhdmUgc3VjaCBrZXJuZWwgZHJpdmVycy4gVGhpcyBoYXMNCj4gYmVlbiB0 cmFkaXRpb25hbGx5IHRoZSBjYXNlIHdpdGggV2luZG93cy4gVGhpcw0KPiA+PiBlbXVsYXRpb24g bGF5ZXIgaGFzIGJlZW4gaW1wbGVtZW50ZWQgaW4gUUVNVSwgd2hpY2ggaGFzIGNhdXNlZA0KPiBW RU5PTSBhbmQgYSBoYW5kZnVsIG9mIG90aGVyIFZNLWVzY2FwZSBidWdzIGluIHJlY2VudA0KPiA+ PiB5ZWFycy4gSG93ZXZlciwgUUVNVSBpcyBub3QgdGhlIG9ubHkgcGxhY2Ugd2hlcmUgZW11bGF0 aW9uIGlzIHVzZWQNCj4gd2l0aGluIFhlbi4gRm9yIGEgdmFyaWV0eSBvZiBpbnRlcnJ1cHRzIGFu ZCB0aW1lcnMsDQo+ID4+IHN1Y2ggYXMgUlRDLCBQSVQsIEhQRVQsIFBNVGltZXIsIFBJQywgSU9B UElDIGFuZCBMQVBJQywgdGhlcmUgaXMgYSBiYWtlZC0NCj4gaW4gZW11bGF0b3IgaW4gWGVuIGl0 c2VsZiBmb3IgcGVyZm9ybWFuY2UgYW5kDQo+ID4+IHNjYWxhYmlsaXR5IHJlYXNvbnMuIEFzIHdp dGggUUVNVSwgdGhpcyBlbXVsYXRvciBoYXMgYmVlbiBqdXN0IGFzDQo+IGV4cGxvaXRhYmxlLiBU aGlzIGlzIHNpbXBseSBiZWNhdXNlIGVtdWxhdGluZyBkZXZpY2VzDQo+ID4+IGFuZCBzZXJ2aWNl cyBpcyByZWFsbHkgY29tcGxleCBhbmQgZXJyb3ItcHJvbmUgdG8gcHJvZ3JhbSBwcm9wZXJseS4N Cj4gPj4NCj4gPj4NCj4gPj4gVGhpcyBmYWN0LCB0aGF0IGVtdWxhdGlvbiBpcyBjb21wbGV4IGFu ZCBlcnJvci1wcm9uZSwgaGFzIGJlZW4ga25vd24gZm9yDQo+IGEgbG9uZyB0aW1lLiBCYWNrIGlu IDIwMTEsIHRoZSBCbGFja2hhdCB0YWxrIG9uDQo+ID4+IFZpcnR1bm9pZCBkZW1vbnN0cmF0ZWQg c3VjaCBhIFZNIGVzY2FwZSBhdHRhY2sgYWdhaW5zdCBLVk0sIHRocm91Z2gNCj4gUUVNVS4gVGhl IGF1dGhvciBvZiBWaXJ0dW5vaWQgZXZlbiBjYXV0aW9uZWQgdGhhdA0KPiA+PiB0aGVyZSB3aWxs IGJlIG1hbnkgb3RoZXIgYnVncyBvZiB0aGF0IG5hdHVyZSBmb3VuZCBieSByZXNlYXJjaGVycy4g RmFzdC0NCj4gZm9yd2FyZCA0IHllYXJzIGFuZCB3ZSBub3cgaGF2ZSBWRU5PTS4NCj4gPj4NCj4g Pj4NCj4gPj4gVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHRoZXJlIGlzIGFuIGVhc3kgbWl0aWdhdGlv biBhdmFpbGFibGUgZm9yIGFsbCBwcmVzZW50DQo+IGFuZCBmdXR1cmUgUUVNVSBidWdzLCBhbHNv IG1lbnRpb25lZCBpbiB0aGUNCj4gPj4gb3JpZ2luYWwgWGVuIFNlY3VyaXR5IEFkdmlzb3J5LiBJ dCBpcyBjYWxsZWQgc3R1YmRvbWFpbnMuIFN0dWJkb21haW5zIGNhbg0KPiBuaXAgdGhlIHdob2xl IGNsYXNzIG9mIHZ1bG5lcmFiaWxpdGllcyBleHBvc2VkDQo+ID4+IGJ5IFFFTVUgaW4gdGhlIGJ1 ZCBieSBtb3ZpbmcgUUVNVSBpbnRvIGEgZGVwcml2aWxlZ2VkIGRvbWFpbiBvZiBpdHMNCj4gb3du LiBJbnN0ZWFkIG9mIGhhdmluZyBRRU1VIHJ1biBhcyByb290IGluIGRvbTAsIGENCj4gPj4gc3R1 YmRvbWFpbiBoYXMgYWNjZXNzIG9ubHkgdG8gdGhlIFZNIGl0IGlzIHByb3ZpZGluZyBlbXVsYXRp b24gZm9yLiBUaHVzLA0KPiBhbiBlc2NhcGUgdGhyb3VnaCBRRU1VIHdpbGwgb25seSBsYW5kIGFu DQo+ID4+IGF0dGFja2VyIGluIGEgc3R1YmRvbWFpbiwgd2l0aG91dCBhY2Nlc3MgdG8gY3JpdGlj YWwgcmVzb3VyY2VzLg0KPiBGdXJ0aGVybW9yZSwgUUVNVSBpbiBhIHN0dWJkb21haW4gcnVucyBv biBNaW5pT1MsIHRodXMgYW4NCj4gPj4gYXR0YWNrZXIgd291bGQgb25seSBoYXZlIGEgdmVyeSBs aW1pdGVkIGVudmlyb25tZW50IHRvIHJ1biBjb2RlIGluIChhcyBpbg0KPiByZXR1cm4tdG8tbGli Yy9ST1Atc3R5bGUpLCBoYXZpbmcgZXhhY3RseSB0aGUNCj4gPj4gc2FtZSBsZXZlbCBvZiBwcml2 aWxlZ2UgYXMgaW4gdGhlIGRvbWFpbiB3aGVyZSB0aGUgYXR0YWNrIHN0YXJ0ZWQuIE5vdGhpbmcN Cj4gdG8gYmUgZ2FpbmVkIGZvciBhIGxvdCBvZiB3b3JrLCBlZmZlY3RpdmVseQ0KPiA+PiBtYWtp bmcgdGhlIHN5c3RlbSBhcyBzZWN1cmUgYXMgaXQgd291bGQgYmUgaWYgb25seSBQViBkcml2ZXJz IHdlcmUgdXNlZC4NCj4gQXMgYSBzaWRlbm90ZSwgS1ZNIGFsbG93cyBmb3Igc2ltaWxhciBqYWls aW5nIG9mDQo+ID4+IHRoZSBRRU1VIHByb2Nlc3MgdmlhIHRoZSBuYXRpdmUgU0VMaW51eCBzVmly dCBwb2xpY2llcy4NCj4gPj4NCj4gPj4NCj4gPj4gT25lIHdvdWxkIHRoaW5rIGl0IGlzIGEgY29t cGxleCBwcm9jZXNzIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoaXMNCj4gcHJvdGVjdGlvbiwgd2hl biBpdCBpcywgaW4gZmFjdCwgdmVyeSBzaW1wbGUuIEFkZCB0aGUNCj4gPj4gZm9sbG93aW5nIGxp bmUgdG8geW91ciBYZW4gZG9tYWluIGNvbmZpZ3VyYXRpb24gYW5kIHlvdSBnYWluIGltbWVkaWF0 ZQ0KPiBwcm90ZWN0aW9uIGFnYWluc3QgVkVOT00sIGFuZCB0aGUgd2hvbGUgY2xhc3Mgb2YNCj4g Pj4gdnVsbmVyYWJpbGl0aWVzIGJyb3VnaHQgdG8geW91IGJ5IFFFTVU6DQo+ID4+DQo+ID4+ICBk ZXZpY2VfbW9kZWxfc3R1YmRvbWFpbl9vdmVycmlkZSA9IDENCj4gPj4NCj4gPj4NCj4gPj4gVW5m b3J0dW5hdGVseSwgeW91ciBjbG91ZCBwcm92aWRlciBtYXkgbm90IGFsbG93IHlvdSB0byBlbmFi bGUgdGhpcw0KPiBvcHRpb24uIFRoZXkgY2VydGFpbmx5IHNob3VsZCwgc28gY29tcGxhaW4gbG91 ZGx5IGFuZA0KPiA+PiByZXBlYXRlZGx5IGlmIHRoYXTigJlzIHRoZSBjYXNlLiBUaGVyZSBpcyBu byByZWFzb24gdG8ga2VlcCB0aGlzIGNsYXNzIG9mIGJ1Z3MNCj4gYWxpdmUuDQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+ID4+IHd3dy5ub3ZldHRhLmNvbQ0KPiA+Pg0KPiA+PiBU YW1hcyBLIExlbmd5ZWwNCj4gPj4NCj4gPj4gU2VuaW9yIFNlY3VyaXR5IFJlc2VhcmNoZXINCj4g Pj4NCj4gPj4NCj4gPj4gNzkyMSBKb25lcyBCcmFuY2ggRHJpdmUNCj4gPj4NCj4gPj4gTWNMZWFu IFZBIDIyMTAyDQo+ID4+DQo+ID4+IEVtYWlsICB0bGVuZ3llbEBub3ZldHRhLmNvbQ0KPiA+Pg0K PiA+Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gUHVibGljaXR5IG1haWxpbmcgbGlzdA0KPiA+IFB1YmxpY2l0eUBsaXN0cy54ZW5wcm9q ZWN0Lm9yZw0KPiA+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4v bGlzdGluZm8vcHVibGljaXR5DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gUHVibGljaXR5IG1haWxpbmcgbGlzdA0KPiBQdWJsaWNp dHlAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2Nn aS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fClB1YmxpY2l0eSBtYWlsaW5nIGxpc3QKUHVibGljaXR5 QGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9jZ2ktYmlu L21haWxtYW4vbGlzdGluZm8vcHVibGljaXR5Cg== From publicity-bounces@lists.xenproject.org Thu May 14 11:14:41 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:14:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr69-0003Al-9M; Thu, 14 May 2015 11:14:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr67-0003AG-Qj for publicity@lists.xenproject.org; Thu, 14 May 2015 11:14:39 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id EA/E2-02948-E9384555; Thu, 14 May 2015 11:14:38 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-31.messagelabs.com!1431602077!11636609!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24727 invoked from network); 14 May 2015 11:14:38 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 May 2015 11:14:38 -0000 Received: from dhcp-172-17-159-45.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id ef9960c3; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 14 May 2015 12:07:57 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 14 May 2015 12:07:56 +0100 Message-Id: <7CE2A8E0-D9AB-4015-A9AD-E04758F53F68@recoil.org> References: <55547EFA.8060504@eu.citrix.com> To: Stefano Stabellini X-Mailer: Apple Mail (2.2098) Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On 14 May 2015, at 11:59, Stefano Stabellini wrote: > > On Thu, 14 May 2015, George Dunlap wrote: >> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: >>> Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. >>> >>> Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. >> >> Well the main reason is that qemu-upstream doesn't work with stub >> domains yet. Anthony worked on it for what, a year? He got pretty far >> but there are just a lot of thorny issues to deal with. > > To be fair, there are also other reasons: memory overhead, number of > domains doubling, and the additional complexity of having 2 QEMUs for > each domain (there is still one QEMU in Dom0 running for each guest, > although it just provides the PV backends). > Perhaps just noting some of the downsides in the blog post would be a little more balanced. Right now it just instructs users to go hassle their cloud provider, who will bounce right back to xen-devel with these sorts of questions :-) -a _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 11:14:41 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:14:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr69-0003Al-9M; Thu, 14 May 2015 11:14:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysr67-0003AG-Qj for publicity@lists.xenproject.org; Thu, 14 May 2015 11:14:39 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id EA/E2-02948-E9384555; Thu, 14 May 2015 11:14:38 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-31.messagelabs.com!1431602077!11636609!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24727 invoked from network); 14 May 2015 11:14:38 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 May 2015 11:14:38 -0000 Received: from dhcp-172-17-159-45.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id ef9960c3; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Thu, 14 May 2015 12:07:57 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Anil Madhavapeddy In-Reply-To: Date: Thu, 14 May 2015 12:07:56 +0100 Message-Id: <7CE2A8E0-D9AB-4015-A9AD-E04758F53F68@recoil.org> References: <55547EFA.8060504@eu.citrix.com> To: Stefano Stabellini X-Mailer: Apple Mail (2.2098) Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org On 14 May 2015, at 11:59, Stefano Stabellini wrote: > > On Thu, 14 May 2015, George Dunlap wrote: >> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: >>> Yeah... it's worth noting that unikernels like MirageOS or HaLVM never use the x86 device emulation and so require a far easier to audit hypervisor TCB that doesn't involve qemu. >>> >>> Also, is it worth mentioning why the qemu stub domain isn't the default? Is it all compiled and installed in most of the hypervisor distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qemu stub domains, although that might have changed in the recent release. >> >> Well the main reason is that qemu-upstream doesn't work with stub >> domains yet. Anthony worked on it for what, a year? He got pretty far >> but there are just a lot of thorny issues to deal with. > > To be fair, there are also other reasons: memory overhead, number of > domains doubling, and the additional complexity of having 2 QEMUs for > each domain (there is still one QEMU in Dom0 running for each guest, > although it just provides the PV backends). > Perhaps just noting some of the downsides in the blog post would be a little more balanced. Right now it just instructs users to go hassle their cloud provider, who will bounce right back to xen-devel with these sorts of questions :-) -a _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Thu May 14 11:40:11 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:40:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsrUo-0007Un-1c; Thu, 14 May 2015 11:40:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsrUl-0007Uf-SL for publicity@lists.xenproject.org; Thu, 14 May 2015 11:40:08 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 4D/70-02948-69984555; Thu, 14 May 2015 11:40:06 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1431603605!15414490!1 X-Originating-IP: [209.85.212.172] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29997 invoked from network); 14 May 2015 11:40:05 -0000 Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com) (209.85.212.172) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:40:05 -0000 Received: by wibt6 with SMTP id t6so11847816wib.0 for ; Thu, 14 May 2015 04:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JoBKH0grLXwN+0+H3tbUXc7x0M0eEDCP0JOpuRfmG7E=; b=ObmPb/knyGy7B1FDkDWagc+TddmbNL4BJ4QhFJQuvA+99bSoY6NjELQ3HaA1CRXOXZ F6WHvDW4DRcnWrC5VLfKabiTrMG/S4O4qm1QhppPYu4YB/lYws24UMdNGG+dB5/bvTrW dvZjomAZWXrK1xUjuRw7cE1ZssmWK2eE+Mu3RxQIYiLd0eDNG0B+Gkh6h2Dke5LQvfgM OBXlRPpcSIwjqfHehRix61uGX6Q+kHNGsft90waoW8Q6Dja6/RQxYRGVlupnYIq2TsaJ RYLi2ZftH3Wt5SNqaRb0DBFB+yYXhep+e1RbYaq3CdExhOh1hfwyPkyd2lumMrufpZgW UnHA== X-Received: by 10.180.74.104 with SMTP id s8mr15231783wiv.40.1431603605187; Thu, 14 May 2015 04:40:05 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id ex5sm12872694wib.2.2015.05.14.04.40.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 04:40:03 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 12:40:02 +0100 Message-Id: <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> References: <55547EFA.8060504@eu.citrix.com> To: Stefano Stabellini X-Mailer: Apple Mail (2.2098) Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org SGkgZm9sa3MsCgphbHRob3VnaCBhIGxvdCBvZiBpbnRlcmVzdGluZyBzdWdnZXN0aW9ucyB3ZXJl IHJhaXNlZCwgSSB0aGluayBpdCBpcyBtb3JlIGhlbHBmdWwgdG8gcHJvcG9zZSBjb25jcmV0ZSB0 ZXh0IGNoYW5nZXMgb3IgYWRkaXRpb25zLCByYXRoZXIgdGhhbiBzdWdnZXN0aW9ucyB3aGljaCBy ZXF1aXJlIHRoYXQgdGhlIGF1dGhvciBkb2VzIGFkZGl0aW9uYWwgcmVzZWFyY2guCgo+IEFsc28s IGlzIGl0IHdvcnRoIG1lbnRpb25pbmcgd2h5IHRoZSBxZW11IHN0dWIgZG9tYWluIGlzbid0IHRo ZSBkZWZhdWx0PyAgSXMgaXQgYWxsIGNvbXBpbGVkIGFuZCBpbnN0YWxsZWQgaW4gbW9zdCBvZiB0 aGUgaHlwZXJ2aXNvciBkaXN0cmlidXRpb25zIG9uIFVidW50dS9DZW50T1MvZXRjPyAgSSBkb24n dCB0aGluayBldmVuIFhlblNlcnZlciB1c2VzIHFlbXUgc3R1YiBkb21haW5zLCBhbHRob3VnaCB0 aGF0IG1pZ2h0IGhhdmUgY2hhbmdlZCBpbiB0aGUgcmVjZW50IHJlbGVhc2UuCgpJcyB0aGVyZSBh IGNvbmNsdXNpb24gb3IgYSBjb25jcmV0ZSBwYXJhZ3JhcGggb24gdGhpcyBvbmUgdGhhdCB5b3Ug Y2FuIHN1Z2dlc3Q/IEkgZGlkIGNoZWNrIFVidW50dSBhbmQgYSBmZXcgb3RoZXIgZGlzdHJvcyBh bmQgdGhleSBhbGwgaGF2ZSBzdHViIGRvbWFpbnMuIFhlblNlcnZlciBtYXkgbm90IGhhdmUuIEJ1 dCB0aGUgZG9tYWluIG1heSBvZiBjb3Vyc2Ugbm90IGJlIGJ1aWx0LCBldmVuIHRob3VnaCB0aGUg Ckkgc3VwcG9zZSBhbnkgb3V0Y29tZS9tZW50aW9uIHNob3VsZCBkZWIgaW4gdGhlICJPbmUgd291 bGQgdGhpbmsgdGhpcyBpcyBhIGNvbXBsZXguLi4uIgoKQFRhbWFzOgoKSSB3b3VsZCBwcm9wb3Nl IHRvIHBvc2l0aW9uIHRoaXMgYXMgYSBndWVzdCBibG9nIHBvc3Q6IHdlIG5vcm1hbGx5IGRvIHRo aXMgZm9yIHNvbWVvbmVzIDFzdCBibG9nIHBvc3Qgb24geGVucHJvamVjdC5vcmcuIE5vcm1hbGx5 IHdoYXQgd2UgZG8gaW4gc3VjaCBjYXNlcyBpcyB0byBhZGQgYSBwcmUtYW1ibGUuIEFuIGV4YW1w bGUgaXM6ICJUaGlzIGlzIGEgZ3Vlc3QgYmxvZyBwb3N0IGJ5IEdlb3JnIETDtnJuLCBhIGxvbmct dGltZSBzeXN0ZW0gYWRtaW5pc3RyYXRvciBhbmQgb3BlbiBzb3VyY2UgZW50aHVzaWFzdC4gR2Vv cmcgZm91bmRlZCBoaXMgY29tcGFueSBpdHMtZG9lcm4gaW4gMjAwOCwgdG8gZGV2ZWxvcCBzb2x1 dGlvbnMgZm9yIGN1c3RvbWVycyBlbnRpcmVseSBmcm9tIG9wZW4gc291cmNlIHNvZnR3YXJlLiIK CklmIHlvdSBjb3VsZCBhZGQgYSBicmllZiBkZXNjcmlwdGlvbiB0aGF0IHdvdWxkIGJlIGdyZWF0 LgoKPiBUaGUgcmVjZW50IGRpc2Nsb3N1cmUgb2YgdGhlIFZFTk9NIGJ1ZyBhZmZlY3RpbmcgbWFq b3Igb3Blbi1zb3VyY2UgaHlwZXJ2aXNvcnMsIHN1Y2ggYXMgS1ZNIGFuZCBYZW4sIGhhcyBiZWVu IGNpcmN1bGF0aW5nIGluIHRoZSB0ZWNoIG5ld3MgbGF0ZWx5LCBjYXVzaW5nIApob3cgYWJvdXQg cmVwbGFjaW5nIGxhdGVseSB3aXRoIGEgZGF0ZQo+IG1hbnkgdG8gcmVldmFsdWF0ZSB0aGVpciBz ZWN1cml0eSBwb3N0dXJlIHdoZW4gdXNpbmcgY2xvdWQgaW5mcmFzdHJ1Y3R1cmVzLiBUaGF0IGlz IGEgdmVyeSBnb29kIHRoaW5nIGluZGVlZC4gVmlydHVhbGl6YXRpb24gYW5kIHRoZSBjbG91ZCBo YXMgYmVlbiBmb3IgdG9vIGxvbmcgCkkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSBzZWN1 cml0eSBwb3N0dXJlOiBtYXliZSBhIG1vcmUgY29tbW9uIHBocmFzZSB3b3VsZCBiZSBiZXR0ZXIg b3IgYW4gZXhhbXBsZS4gCgpJIGFsc28gdGhpbmsgdGhhdCBzb21lIG9mIHRoZSBtb3JlIHJlY2Vu dCBWZW5vbSBhcnRpY2xlcyBhcmUgcGFydGx5IGFsc28gY2FsbGluZyBvdXQgdGhlIFZlbm9tIGNv dmVyYWdlIGEgY2xldmVyIG1hcmtldGluZyBjYW1wYWlnbiBieSBDcm93ZFN0cmlrZSB0byByYWlz ZSB0aGVpciBwcm9maWxlIGFuZCBpdCBpcyBhbHNvIG5vdyBjbGVhciB0aGF0IGZhciBmZXdlciB2 ZW5kb3JzIHRoYW4gb3JpZ2luYWxseSBhbnRpY2lwYXRlZCBhcmUgYWZmZWN0ZWQgYnkgVmVub20K KiBodHRwOi8vd3d3LmNzb29ubGluZS5jb20vYXJ0aWNsZS8yOTIyMDY2L3Z1bG5lcmFiaWxpdGll cy92ZW5vbS1oeXBlLWFuZC1wcmUtcGxhbm5lZC1tYXJrZXRpbmctY2FtcGFpZ24tcGFubmVkLWJ5 LWV4cGVydHMuaHRtbAoqIGh0dHA6Ly9naXptb2RvLmNvbS9wbGVhc2Utc3RvcC1jb21wYXJpbmct ZXZlcnktc2VjdXJpdHktZmxhdy10by1oZWFydGJsZWVkLTE3MDQyNTk0OTUKKiBodHRwOi8vd3d3 LmZvcmJlcy5jb20vc2l0ZXMvdGhvbWFzYnJld3N0ZXIvMjAxNS8wNS8xMy92ZW5vbS12dWxuZXJh YmlsaXR5LWNvdWxkLWhpdC1hbWF6b24tb3JhY2xlLXJhY2tzcGFjZS1jaXRyaXgvCiogaHR0cDov L3d3dy50aGVyZWdpc3Rlci5jby51ay8yMDE1LzA1LzEzL2hlYXJ0YmxlZWRfZWF0X3lvdXJfaGVh cnRfb3V0X3Zlbm9tX3Z1bG5fcG9pc29uc19jb3VudGxlc3Nfdm1zLwoqIGh0dHA6Ly93d3cuemRu ZXQuY29tL2FydGljbGUvdmVub20tdGhlLWFudGktdG94aW4taXMtaGVyZS8KCj4gZXJyb25lb3Vz bHkgY29uc2lkZXJlZCB0byBiZSBhIHNpbHZlciBidWxsZXQgYWdhaW5zdCBpbnRydXNpb25zLCBt YWx3YXJlIGFuZCBBUFRzLgpXaGF0IGlzIGFuIEFQVD8KCj4gVGhlIGNsb3VkIGlzIGFueXRoaW5n IGJ1dCBhIHNhZmUgcGxhY2UuIApJIGFtIG5vdCBzdXJlIHdlIHdhbnQgdG8gc2luZ2xlIG91dCB0 aGUgY2xvdWQuIE1heWJlLCBleHBhbmQgdGhlIGxpc3QgYSBiaXQsIGUuZy4gdGhlICJpbnRlcm5l dCBhbmQgY2xvdWQiLiBBZnRlciBhbGwgd2UgYXJlIG5vIHdvcnNlIHRoYW4gb3RoZXIgc29mdHdh cmUgc3RhY2tzLiBNYXliZSB3ZSBoYXZlIGEgYmV0dGVyIHRyYWNrIHJlY29yZCB0aGFuIG1vc3Qu IAoKPiBWRU5PTSBpbiB0aGF0IHNlbnNlIGlzIGp1c3QgYW5vdGhlciBvbmUgaW4gdGhlIGxvbmcg bGlzdCBvZiB2dWxuZXJhYmlsaXRpZXMgdGhhdCBzZWVtIHRvIGJlIHBsYWd1aW5nIGh5cGVydmlz b3JzLiAKQWdhaW4sIG1heWJlIG5vdCBzaW5nbGUgb3V0IGh5cGVydmlzb3JzCgo+IEhvd2V2ZXIs IHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHZ1bG5lcmFiaWxpdGllcy4gV2hpbGUgVkVO T00gaXMgaW5kZWVkIGEgc2VyaW91cyBidWcgYW5kIGNhbiByZXN1bHQgaW4gYSBWTSBlc2NhcGUs IHdoaWNoIGNhbiBjb21wcm9taXNlIGFsbCBWTXMgb24gCj4gdGhlIGhvc3QsIGl0IGRvZXNu4oCZ dCBoYXZlIHRvIGJlLiBJbiBmYWN0LCBWRU5PTS1zdHlsZSBhdHRhY2tzIGhhdmUgYmVlbiBrbm93 biBmb3IgYSBsb25nIHRpbWUuIEFuZCB0aGVyZSBhcmUgZWFzeS10by1kZXBsb3kgY28KPiB1bnRl ci1tZWFzdXJlcyB0byBtaXRpZ2F0ZSB0aGUgcmlzayBvZiBzdWNoIGV4cGxvaXRzLCBuYXRpdmVs eSBhdmFpbGFibGUgaW4gWGVuIGFuZCBLVk0uCkFyZSB0aGVyZSB3YXlzIHRvIG1pdGlnYXRlIHRo aXMgZm9yIEtWTT8gV2hlbiBJIHJlYWQgdGhpcyBJIHdhcyBleHBlY3RpbmcgdG8gcmVhZCBhYm91 dCBLVk0gYWxzby4gU28gbWF5YmUgZHJvcCBLVk0gaGVyZSwgYXMgaXQgZmVlbHMgbGlrZSBhIGxv b3NlIGVuZHMuCkFjdHVhbGx5IHJlLXJlYWRpbmcgdGhpcyBhZ2FpbiwgeW91IGRvIG1lbnRpb24g S1ZNIHNWaXJ0IFNFTGludXggcG9saWNpZXM6IGl0J3MgZWFzeSB0byBtaXNzIGJlY2F1c2UgdGhh dCBwYXJhZ3JhcGggaXMgZW1iZWRkZWQgaW50byBhIGxvbmdlciBzZWN0aW9uIGFib3V0IHN0dWIg ZG9tYWlucy4gTWF5YmUgYWRkIHNvbWV0aGluZyBpbW1lZGlhdGVseSBhZnRlcndhcmRzIGFsb25n IHRoZSBsaW5lcyBvZiAiWGVuIHByb3ZpZGVzIHN1YmRvbWFpbnMgdG8gc2FuZGJveCBWRU5PTSBz dHlsZSBleHBsb2l0cyBpbiBhIGRlLXByaXZpbGVkZ2VkIGRvbWFvbiBhbmQgS1ZNIGFsbG93cyBm b3Igc2ltaWxhciBqYWlsaW5nIG9mIHRoZSBRRU1VIHByb2Nlc3MgdmlhIHRoZSBuYXRpdmUgU0VM aW51eCBzVmlydCBwb2xpY2llcy4iCgo+IFdoaWxlIG1vZGVybiBzeXN0ZW1zIGNvbWUgLi4uCj4g RGV2aWNlcyBzdWNoIGFzIHlvdXIgbmV0d29yayBjYXJkLCBncmFwaGljcyBjYXJkIGFuZCB5b3Vy IGhhcmQgZHJpdmUuIFdoaWxlIExpbnV4IGNvbWVzIHdpdGggcGFyYXZpcnR1YWwgKHZpcnR1YWxp emF0aW9uLWF3YXJlKSBkcml2ZXJzIHRvIGNyZWF0ZSBzdWNoIGRldmljZXMsID4gPiBlbXVsYXRp b24gaXMgb2Z0ZW4gdGhlIG9ubHkgc29sdXRpb24gdG8gcnVuIG9wZXJhdGluZyBzeXN0ZW1zIHRo YXQgZG8gbm90IGhhdmUgc3VjaCBrZXJuZWwgZHJpdmVycy4gVGhpcyBoYXMgYmVlbiB0cmFkaXRp b25hbGx5IHRoZSBjYXNlIHdpdGggV2luZG93cy4gVGhpcyAKPiBlbXVsYXRpb24gbGF5ZXIgaGFz IGJlZW4gaW1wbGVtZW50ZWQgaW4gUUVNVSwgd2hpY2ggaGFzIGNhdXNlZCBWRU5PTSBhbmQgYSBo YW5kZnVsIG9mIG90aGVyIFZNLWVzY2FwZSBidWdzIGluIHJlY2VudCB5ZWFycwpNYXliZSBsaXN0 IHNvbWUgZXhhbXBsZXMgcmUgUUVNVSByZWxhdGVkIFZNLWVzY2FwZWQgYnVncwpJIHRoaW5rIGl0 IGlzIHdvcnRoIHBvaW50aW5nIHBvdXQgdGhhdCBwZW9wbGUgdXNlIFBWSFZNIChIVk0pIGZvciBw ZXJmb3JtYW5jZSByZWFzb25zIGFsc28uIE9uZSBnZXRzIHRoZSBpbXByZXNzaW9uIGZyb20gdGhp cyBwYXJhZ3JhcGggdGhhdCB0aGUgb25seSByZWFzb24gCgo+IEJhY2sgaW4gMjAxMSwgdGhlIEJs YWNraGF0IHRhbGsgb24gVmlydHVub2lkIGRlbW9uc3RyYXRlZCBzdWNoIGEgVk0gZXNjYXBlIGF0 dGFjayBhZ2FpbnN0IEtWTSwgdGhyb3VnaCBRRU1VLgpMaW5rPwoKPiBBcyBhIHNpZGVub3RlLCBL Vk0gYWxsb3dzIGZvciBzaW1pbGFyIGphaWxpbmcgb2YgdGhlIFFFTVUgcHJvY2VzcyB2aWEgdGhl IG5hdGl2ZSBTRUxpbnV4IHNWaXJ0IHBvbGljaWVzLgpTZWUgYWJvdmUKCj4gT25lIHdvdWxkIHRo aW5rIGl0IGlzIGEgY29tcGxleCBwcm9jZXNzIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoaXMgcHJv dGVjdGlvbiwKTWF5YmUgbGluayB0byBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9yZy93aWtpL0Rl dmljZV9Nb2RlbF9TdHViX0RvbWFpbnMKCj4gVW5mb3J0dW5hdGVseSwgeW91ciBjbG91ZCBwcm92 aWRlciBtYXkgbm90IGFsbG93IHlvdSB0byBlbmFibGUgdGhpcyBvcHRpb24uCllvdSBzaG91bGQg cHJvYmFibHkgYWxzbyBjYWxsIG91dCBkaXN0cm9zCgpSZWdhcmRzCkxhcnMKCj4gT24gMTQgTWF5 IDIwMTUsIGF0IDExOjU5LCBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBl dS5jaXRyaXguY29tPiB3cm90ZToKPiAKPiBPbiBUaHUsIDE0IE1heSAyMDE1LCBHZW9yZ2UgRHVu bGFwIHdyb3RlOgo+PiBPbiAwNS8xNC8yMDE1IDExOjM5IEFNLCBBbmlsIE1hZGhhdmFwZWRkeSB3 cm90ZToKPj4+IFllYWguLi4gaXQncyB3b3J0aCBub3RpbmcgdGhhdCB1bmlrZXJuZWxzIGxpa2Ug TWlyYWdlT1Mgb3IgSGFMVk0gbmV2ZXIgdXNlIHRoZSB4ODYgZGV2aWNlIGVtdWxhdGlvbiBhbmQg c28gcmVxdWlyZSBhIGZhciBlYXNpZXIgdG8gYXVkaXQgaHlwZXJ2aXNvciBUQ0IgdGhhdCBkb2Vz bid0IGludm9sdmUgcWVtdS4KPj4+IAo+Pj4gQWxzbywgaXMgaXQgd29ydGggbWVudGlvbmluZyB3 aHkgdGhlIHFlbXUgc3R1YiBkb21haW4gaXNuJ3QgdGhlIGRlZmF1bHQ/ICBJcyBpdCBhbGwgY29t cGlsZWQgYW5kIGluc3RhbGxlZCBpbiBtb3N0IG9mIHRoZSBoeXBlcnZpc29yIGRpc3RyaWJ1dGlv bnMgb24gVWJ1bnR1L0NlbnRPUy9ldGM/ICBJIGRvbid0IHRoaW5rIGV2ZW4gWGVuU2VydmVyIHVz ZXMgcWVtdSBzdHViIGRvbWFpbnMsIGFsdGhvdWdoIHRoYXQgbWlnaHQgaGF2ZSBjaGFuZ2VkIGlu IHRoZSByZWNlbnQgcmVsZWFzZS4KPj4gCj4+IFdlbGwgdGhlIG1haW4gcmVhc29uIGlzIHRoYXQg cWVtdS11cHN0cmVhbSBkb2Vzbid0IHdvcmsgd2l0aCBzdHViCj4+IGRvbWFpbnMgeWV0LiAgQW50 aG9ueSB3b3JrZWQgb24gaXQgZm9yIHdoYXQsIGEgeWVhcj8gIEhlIGdvdCBwcmV0dHkgZmFyCj4+ IGJ1dCB0aGVyZSBhcmUganVzdCBhIGxvdCBvZiB0aG9ybnkgaXNzdWVzIHRvIGRlYWwgd2l0aC4K PiAKPiBUbyBiZSBmYWlyLCB0aGVyZSBhcmUgYWxzbyBvdGhlciByZWFzb25zOiBtZW1vcnkgb3Zl cmhlYWQsIG51bWJlciBvZgo+IGRvbWFpbnMgZG91YmxpbmcsIGFuZCB0aGUgYWRkaXRpb25hbCBj b21wbGV4aXR5IG9mIGhhdmluZyAyIFFFTVVzIGZvcgo+IGVhY2ggZG9tYWluICh0aGVyZSBpcyBz dGlsbCBvbmUgUUVNVSBpbiBEb20wIHJ1bm5pbmcgZm9yIGVhY2ggZ3Vlc3QsCj4gYWx0aG91Z2gg aXQganVzdCBwcm92aWRlcyB0aGUgUFYgYmFja2VuZHMpLgo+IAo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gUHVibGljaXR5IG1haWxpbmcgbGlzdAo+ IFB1YmxpY2l0eUBsaXN0cy54ZW5wcm9qZWN0Lm9yZwo+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0 Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vcHVibGljaXR5CgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5IG1haWxpbmcgbGlzdApQ dWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3Jn L2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK From publicity-bounces@lists.xenproject.org Thu May 14 11:40:11 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 11:40:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsrUo-0007Un-1c; Thu, 14 May 2015 11:40:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsrUl-0007Uf-SL for publicity@lists.xenproject.org; Thu, 14 May 2015 11:40:08 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 4D/70-02948-69984555; Thu, 14 May 2015 11:40:06 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1431603605!15414490!1 X-Originating-IP: [209.85.212.172] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29997 invoked from network); 14 May 2015 11:40:05 -0000 Received: from mail-wi0-f172.google.com (HELO mail-wi0-f172.google.com) (209.85.212.172) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 11:40:05 -0000 Received: by wibt6 with SMTP id t6so11847816wib.0 for ; Thu, 14 May 2015 04:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JoBKH0grLXwN+0+H3tbUXc7x0M0eEDCP0JOpuRfmG7E=; b=ObmPb/knyGy7B1FDkDWagc+TddmbNL4BJ4QhFJQuvA+99bSoY6NjELQ3HaA1CRXOXZ F6WHvDW4DRcnWrC5VLfKabiTrMG/S4O4qm1QhppPYu4YB/lYws24UMdNGG+dB5/bvTrW dvZjomAZWXrK1xUjuRw7cE1ZssmWK2eE+Mu3RxQIYiLd0eDNG0B+Gkh6h2Dke5LQvfgM OBXlRPpcSIwjqfHehRix61uGX6Q+kHNGsft90waoW8Q6Dja6/RQxYRGVlupnYIq2TsaJ RYLi2ZftH3Wt5SNqaRb0DBFB+yYXhep+e1RbYaq3CdExhOh1hfwyPkyd2lumMrufpZgW UnHA== X-Received: by 10.180.74.104 with SMTP id s8mr15231783wiv.40.1431603605187; Thu, 14 May 2015 04:40:05 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id ex5sm12872694wib.2.2015.05.14.04.40.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 04:40:03 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 12:40:02 +0100 Message-Id: <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> References: <55547EFA.8060504@eu.citrix.com> To: Stefano Stabellini X-Mailer: Apple Mail (2.2098) Cc: "Lengyel, Tamas" , publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org SGkgZm9sa3MsCgphbHRob3VnaCBhIGxvdCBvZiBpbnRlcmVzdGluZyBzdWdnZXN0aW9ucyB3ZXJl IHJhaXNlZCwgSSB0aGluayBpdCBpcyBtb3JlIGhlbHBmdWwgdG8gcHJvcG9zZSBjb25jcmV0ZSB0 ZXh0IGNoYW5nZXMgb3IgYWRkaXRpb25zLCByYXRoZXIgdGhhbiBzdWdnZXN0aW9ucyB3aGljaCBy ZXF1aXJlIHRoYXQgdGhlIGF1dGhvciBkb2VzIGFkZGl0aW9uYWwgcmVzZWFyY2guCgo+IEFsc28s IGlzIGl0IHdvcnRoIG1lbnRpb25pbmcgd2h5IHRoZSBxZW11IHN0dWIgZG9tYWluIGlzbid0IHRo ZSBkZWZhdWx0PyAgSXMgaXQgYWxsIGNvbXBpbGVkIGFuZCBpbnN0YWxsZWQgaW4gbW9zdCBvZiB0 aGUgaHlwZXJ2aXNvciBkaXN0cmlidXRpb25zIG9uIFVidW50dS9DZW50T1MvZXRjPyAgSSBkb24n dCB0aGluayBldmVuIFhlblNlcnZlciB1c2VzIHFlbXUgc3R1YiBkb21haW5zLCBhbHRob3VnaCB0 aGF0IG1pZ2h0IGhhdmUgY2hhbmdlZCBpbiB0aGUgcmVjZW50IHJlbGVhc2UuCgpJcyB0aGVyZSBh IGNvbmNsdXNpb24gb3IgYSBjb25jcmV0ZSBwYXJhZ3JhcGggb24gdGhpcyBvbmUgdGhhdCB5b3Ug Y2FuIHN1Z2dlc3Q/IEkgZGlkIGNoZWNrIFVidW50dSBhbmQgYSBmZXcgb3RoZXIgZGlzdHJvcyBh bmQgdGhleSBhbGwgaGF2ZSBzdHViIGRvbWFpbnMuIFhlblNlcnZlciBtYXkgbm90IGhhdmUuIEJ1 dCB0aGUgZG9tYWluIG1heSBvZiBjb3Vyc2Ugbm90IGJlIGJ1aWx0LCBldmVuIHRob3VnaCB0aGUg Ckkgc3VwcG9zZSBhbnkgb3V0Y29tZS9tZW50aW9uIHNob3VsZCBkZWIgaW4gdGhlICJPbmUgd291 bGQgdGhpbmsgdGhpcyBpcyBhIGNvbXBsZXguLi4uIgoKQFRhbWFzOgoKSSB3b3VsZCBwcm9wb3Nl IHRvIHBvc2l0aW9uIHRoaXMgYXMgYSBndWVzdCBibG9nIHBvc3Q6IHdlIG5vcm1hbGx5IGRvIHRo aXMgZm9yIHNvbWVvbmVzIDFzdCBibG9nIHBvc3Qgb24geGVucHJvamVjdC5vcmcuIE5vcm1hbGx5 IHdoYXQgd2UgZG8gaW4gc3VjaCBjYXNlcyBpcyB0byBhZGQgYSBwcmUtYW1ibGUuIEFuIGV4YW1w bGUgaXM6ICJUaGlzIGlzIGEgZ3Vlc3QgYmxvZyBwb3N0IGJ5IEdlb3JnIETDtnJuLCBhIGxvbmct dGltZSBzeXN0ZW0gYWRtaW5pc3RyYXRvciBhbmQgb3BlbiBzb3VyY2UgZW50aHVzaWFzdC4gR2Vv cmcgZm91bmRlZCBoaXMgY29tcGFueSBpdHMtZG9lcm4gaW4gMjAwOCwgdG8gZGV2ZWxvcCBzb2x1 dGlvbnMgZm9yIGN1c3RvbWVycyBlbnRpcmVseSBmcm9tIG9wZW4gc291cmNlIHNvZnR3YXJlLiIK CklmIHlvdSBjb3VsZCBhZGQgYSBicmllZiBkZXNjcmlwdGlvbiB0aGF0IHdvdWxkIGJlIGdyZWF0 LgoKPiBUaGUgcmVjZW50IGRpc2Nsb3N1cmUgb2YgdGhlIFZFTk9NIGJ1ZyBhZmZlY3RpbmcgbWFq b3Igb3Blbi1zb3VyY2UgaHlwZXJ2aXNvcnMsIHN1Y2ggYXMgS1ZNIGFuZCBYZW4sIGhhcyBiZWVu IGNpcmN1bGF0aW5nIGluIHRoZSB0ZWNoIG5ld3MgbGF0ZWx5LCBjYXVzaW5nIApob3cgYWJvdXQg cmVwbGFjaW5nIGxhdGVseSB3aXRoIGEgZGF0ZQo+IG1hbnkgdG8gcmVldmFsdWF0ZSB0aGVpciBz ZWN1cml0eSBwb3N0dXJlIHdoZW4gdXNpbmcgY2xvdWQgaW5mcmFzdHJ1Y3R1cmVzLiBUaGF0IGlz IGEgdmVyeSBnb29kIHRoaW5nIGluZGVlZC4gVmlydHVhbGl6YXRpb24gYW5kIHRoZSBjbG91ZCBo YXMgYmVlbiBmb3IgdG9vIGxvbmcgCkkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSBzZWN1 cml0eSBwb3N0dXJlOiBtYXliZSBhIG1vcmUgY29tbW9uIHBocmFzZSB3b3VsZCBiZSBiZXR0ZXIg b3IgYW4gZXhhbXBsZS4gCgpJIGFsc28gdGhpbmsgdGhhdCBzb21lIG9mIHRoZSBtb3JlIHJlY2Vu dCBWZW5vbSBhcnRpY2xlcyBhcmUgcGFydGx5IGFsc28gY2FsbGluZyBvdXQgdGhlIFZlbm9tIGNv dmVyYWdlIGEgY2xldmVyIG1hcmtldGluZyBjYW1wYWlnbiBieSBDcm93ZFN0cmlrZSB0byByYWlz ZSB0aGVpciBwcm9maWxlIGFuZCBpdCBpcyBhbHNvIG5vdyBjbGVhciB0aGF0IGZhciBmZXdlciB2 ZW5kb3JzIHRoYW4gb3JpZ2luYWxseSBhbnRpY2lwYXRlZCBhcmUgYWZmZWN0ZWQgYnkgVmVub20K KiBodHRwOi8vd3d3LmNzb29ubGluZS5jb20vYXJ0aWNsZS8yOTIyMDY2L3Z1bG5lcmFiaWxpdGll cy92ZW5vbS1oeXBlLWFuZC1wcmUtcGxhbm5lZC1tYXJrZXRpbmctY2FtcGFpZ24tcGFubmVkLWJ5 LWV4cGVydHMuaHRtbAoqIGh0dHA6Ly9naXptb2RvLmNvbS9wbGVhc2Utc3RvcC1jb21wYXJpbmct ZXZlcnktc2VjdXJpdHktZmxhdy10by1oZWFydGJsZWVkLTE3MDQyNTk0OTUKKiBodHRwOi8vd3d3 LmZvcmJlcy5jb20vc2l0ZXMvdGhvbWFzYnJld3N0ZXIvMjAxNS8wNS8xMy92ZW5vbS12dWxuZXJh YmlsaXR5LWNvdWxkLWhpdC1hbWF6b24tb3JhY2xlLXJhY2tzcGFjZS1jaXRyaXgvCiogaHR0cDov L3d3dy50aGVyZWdpc3Rlci5jby51ay8yMDE1LzA1LzEzL2hlYXJ0YmxlZWRfZWF0X3lvdXJfaGVh cnRfb3V0X3Zlbm9tX3Z1bG5fcG9pc29uc19jb3VudGxlc3Nfdm1zLwoqIGh0dHA6Ly93d3cuemRu ZXQuY29tL2FydGljbGUvdmVub20tdGhlLWFudGktdG94aW4taXMtaGVyZS8KCj4gZXJyb25lb3Vz bHkgY29uc2lkZXJlZCB0byBiZSBhIHNpbHZlciBidWxsZXQgYWdhaW5zdCBpbnRydXNpb25zLCBt YWx3YXJlIGFuZCBBUFRzLgpXaGF0IGlzIGFuIEFQVD8KCj4gVGhlIGNsb3VkIGlzIGFueXRoaW5n IGJ1dCBhIHNhZmUgcGxhY2UuIApJIGFtIG5vdCBzdXJlIHdlIHdhbnQgdG8gc2luZ2xlIG91dCB0 aGUgY2xvdWQuIE1heWJlLCBleHBhbmQgdGhlIGxpc3QgYSBiaXQsIGUuZy4gdGhlICJpbnRlcm5l dCBhbmQgY2xvdWQiLiBBZnRlciBhbGwgd2UgYXJlIG5vIHdvcnNlIHRoYW4gb3RoZXIgc29mdHdh cmUgc3RhY2tzLiBNYXliZSB3ZSBoYXZlIGEgYmV0dGVyIHRyYWNrIHJlY29yZCB0aGFuIG1vc3Qu IAoKPiBWRU5PTSBpbiB0aGF0IHNlbnNlIGlzIGp1c3QgYW5vdGhlciBvbmUgaW4gdGhlIGxvbmcg bGlzdCBvZiB2dWxuZXJhYmlsaXRpZXMgdGhhdCBzZWVtIHRvIGJlIHBsYWd1aW5nIGh5cGVydmlz b3JzLiAKQWdhaW4sIG1heWJlIG5vdCBzaW5nbGUgb3V0IGh5cGVydmlzb3JzCgo+IEhvd2V2ZXIs IHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHZ1bG5lcmFiaWxpdGllcy4gV2hpbGUgVkVO T00gaXMgaW5kZWVkIGEgc2VyaW91cyBidWcgYW5kIGNhbiByZXN1bHQgaW4gYSBWTSBlc2NhcGUs IHdoaWNoIGNhbiBjb21wcm9taXNlIGFsbCBWTXMgb24gCj4gdGhlIGhvc3QsIGl0IGRvZXNu4oCZ dCBoYXZlIHRvIGJlLiBJbiBmYWN0LCBWRU5PTS1zdHlsZSBhdHRhY2tzIGhhdmUgYmVlbiBrbm93 biBmb3IgYSBsb25nIHRpbWUuIEFuZCB0aGVyZSBhcmUgZWFzeS10by1kZXBsb3kgY28KPiB1bnRl ci1tZWFzdXJlcyB0byBtaXRpZ2F0ZSB0aGUgcmlzayBvZiBzdWNoIGV4cGxvaXRzLCBuYXRpdmVs eSBhdmFpbGFibGUgaW4gWGVuIGFuZCBLVk0uCkFyZSB0aGVyZSB3YXlzIHRvIG1pdGlnYXRlIHRo aXMgZm9yIEtWTT8gV2hlbiBJIHJlYWQgdGhpcyBJIHdhcyBleHBlY3RpbmcgdG8gcmVhZCBhYm91 dCBLVk0gYWxzby4gU28gbWF5YmUgZHJvcCBLVk0gaGVyZSwgYXMgaXQgZmVlbHMgbGlrZSBhIGxv b3NlIGVuZHMuCkFjdHVhbGx5IHJlLXJlYWRpbmcgdGhpcyBhZ2FpbiwgeW91IGRvIG1lbnRpb24g S1ZNIHNWaXJ0IFNFTGludXggcG9saWNpZXM6IGl0J3MgZWFzeSB0byBtaXNzIGJlY2F1c2UgdGhh dCBwYXJhZ3JhcGggaXMgZW1iZWRkZWQgaW50byBhIGxvbmdlciBzZWN0aW9uIGFib3V0IHN0dWIg ZG9tYWlucy4gTWF5YmUgYWRkIHNvbWV0aGluZyBpbW1lZGlhdGVseSBhZnRlcndhcmRzIGFsb25n IHRoZSBsaW5lcyBvZiAiWGVuIHByb3ZpZGVzIHN1YmRvbWFpbnMgdG8gc2FuZGJveCBWRU5PTSBz dHlsZSBleHBsb2l0cyBpbiBhIGRlLXByaXZpbGVkZ2VkIGRvbWFvbiBhbmQgS1ZNIGFsbG93cyBm b3Igc2ltaWxhciBqYWlsaW5nIG9mIHRoZSBRRU1VIHByb2Nlc3MgdmlhIHRoZSBuYXRpdmUgU0VM aW51eCBzVmlydCBwb2xpY2llcy4iCgo+IFdoaWxlIG1vZGVybiBzeXN0ZW1zIGNvbWUgLi4uCj4g RGV2aWNlcyBzdWNoIGFzIHlvdXIgbmV0d29yayBjYXJkLCBncmFwaGljcyBjYXJkIGFuZCB5b3Vy IGhhcmQgZHJpdmUuIFdoaWxlIExpbnV4IGNvbWVzIHdpdGggcGFyYXZpcnR1YWwgKHZpcnR1YWxp emF0aW9uLWF3YXJlKSBkcml2ZXJzIHRvIGNyZWF0ZSBzdWNoIGRldmljZXMsID4gPiBlbXVsYXRp b24gaXMgb2Z0ZW4gdGhlIG9ubHkgc29sdXRpb24gdG8gcnVuIG9wZXJhdGluZyBzeXN0ZW1zIHRo YXQgZG8gbm90IGhhdmUgc3VjaCBrZXJuZWwgZHJpdmVycy4gVGhpcyBoYXMgYmVlbiB0cmFkaXRp b25hbGx5IHRoZSBjYXNlIHdpdGggV2luZG93cy4gVGhpcyAKPiBlbXVsYXRpb24gbGF5ZXIgaGFz IGJlZW4gaW1wbGVtZW50ZWQgaW4gUUVNVSwgd2hpY2ggaGFzIGNhdXNlZCBWRU5PTSBhbmQgYSBo YW5kZnVsIG9mIG90aGVyIFZNLWVzY2FwZSBidWdzIGluIHJlY2VudCB5ZWFycwpNYXliZSBsaXN0 IHNvbWUgZXhhbXBsZXMgcmUgUUVNVSByZWxhdGVkIFZNLWVzY2FwZWQgYnVncwpJIHRoaW5rIGl0 IGlzIHdvcnRoIHBvaW50aW5nIHBvdXQgdGhhdCBwZW9wbGUgdXNlIFBWSFZNIChIVk0pIGZvciBw ZXJmb3JtYW5jZSByZWFzb25zIGFsc28uIE9uZSBnZXRzIHRoZSBpbXByZXNzaW9uIGZyb20gdGhp cyBwYXJhZ3JhcGggdGhhdCB0aGUgb25seSByZWFzb24gCgo+IEJhY2sgaW4gMjAxMSwgdGhlIEJs YWNraGF0IHRhbGsgb24gVmlydHVub2lkIGRlbW9uc3RyYXRlZCBzdWNoIGEgVk0gZXNjYXBlIGF0 dGFjayBhZ2FpbnN0IEtWTSwgdGhyb3VnaCBRRU1VLgpMaW5rPwoKPiBBcyBhIHNpZGVub3RlLCBL Vk0gYWxsb3dzIGZvciBzaW1pbGFyIGphaWxpbmcgb2YgdGhlIFFFTVUgcHJvY2VzcyB2aWEgdGhl IG5hdGl2ZSBTRUxpbnV4IHNWaXJ0IHBvbGljaWVzLgpTZWUgYWJvdmUKCj4gT25lIHdvdWxkIHRo aW5rIGl0IGlzIGEgY29tcGxleCBwcm9jZXNzIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoaXMgcHJv dGVjdGlvbiwKTWF5YmUgbGluayB0byBodHRwOi8vd2lraS54ZW5wcm9qZWN0Lm9yZy93aWtpL0Rl dmljZV9Nb2RlbF9TdHViX0RvbWFpbnMKCj4gVW5mb3J0dW5hdGVseSwgeW91ciBjbG91ZCBwcm92 aWRlciBtYXkgbm90IGFsbG93IHlvdSB0byBlbmFibGUgdGhpcyBvcHRpb24uCllvdSBzaG91bGQg cHJvYmFibHkgYWxzbyBjYWxsIG91dCBkaXN0cm9zCgpSZWdhcmRzCkxhcnMKCj4gT24gMTQgTWF5 IDIwMTUsIGF0IDExOjU5LCBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBl dS5jaXRyaXguY29tPiB3cm90ZToKPiAKPiBPbiBUaHUsIDE0IE1heSAyMDE1LCBHZW9yZ2UgRHVu bGFwIHdyb3RlOgo+PiBPbiAwNS8xNC8yMDE1IDExOjM5IEFNLCBBbmlsIE1hZGhhdmFwZWRkeSB3 cm90ZToKPj4+IFllYWguLi4gaXQncyB3b3J0aCBub3RpbmcgdGhhdCB1bmlrZXJuZWxzIGxpa2Ug TWlyYWdlT1Mgb3IgSGFMVk0gbmV2ZXIgdXNlIHRoZSB4ODYgZGV2aWNlIGVtdWxhdGlvbiBhbmQg c28gcmVxdWlyZSBhIGZhciBlYXNpZXIgdG8gYXVkaXQgaHlwZXJ2aXNvciBUQ0IgdGhhdCBkb2Vz bid0IGludm9sdmUgcWVtdS4KPj4+IAo+Pj4gQWxzbywgaXMgaXQgd29ydGggbWVudGlvbmluZyB3 aHkgdGhlIHFlbXUgc3R1YiBkb21haW4gaXNuJ3QgdGhlIGRlZmF1bHQ/ICBJcyBpdCBhbGwgY29t cGlsZWQgYW5kIGluc3RhbGxlZCBpbiBtb3N0IG9mIHRoZSBoeXBlcnZpc29yIGRpc3RyaWJ1dGlv bnMgb24gVWJ1bnR1L0NlbnRPUy9ldGM/ICBJIGRvbid0IHRoaW5rIGV2ZW4gWGVuU2VydmVyIHVz ZXMgcWVtdSBzdHViIGRvbWFpbnMsIGFsdGhvdWdoIHRoYXQgbWlnaHQgaGF2ZSBjaGFuZ2VkIGlu IHRoZSByZWNlbnQgcmVsZWFzZS4KPj4gCj4+IFdlbGwgdGhlIG1haW4gcmVhc29uIGlzIHRoYXQg cWVtdS11cHN0cmVhbSBkb2Vzbid0IHdvcmsgd2l0aCBzdHViCj4+IGRvbWFpbnMgeWV0LiAgQW50 aG9ueSB3b3JrZWQgb24gaXQgZm9yIHdoYXQsIGEgeWVhcj8gIEhlIGdvdCBwcmV0dHkgZmFyCj4+ IGJ1dCB0aGVyZSBhcmUganVzdCBhIGxvdCBvZiB0aG9ybnkgaXNzdWVzIHRvIGRlYWwgd2l0aC4K PiAKPiBUbyBiZSBmYWlyLCB0aGVyZSBhcmUgYWxzbyBvdGhlciByZWFzb25zOiBtZW1vcnkgb3Zl cmhlYWQsIG51bWJlciBvZgo+IGRvbWFpbnMgZG91YmxpbmcsIGFuZCB0aGUgYWRkaXRpb25hbCBj b21wbGV4aXR5IG9mIGhhdmluZyAyIFFFTVVzIGZvcgo+IGVhY2ggZG9tYWluICh0aGVyZSBpcyBz dGlsbCBvbmUgUUVNVSBpbiBEb20wIHJ1bm5pbmcgZm9yIGVhY2ggZ3Vlc3QsCj4gYWx0aG91Z2gg aXQganVzdCBwcm92aWRlcyB0aGUgUFYgYmFja2VuZHMpLgo+IAo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gUHVibGljaXR5IG1haWxpbmcgbGlzdAo+ IFB1YmxpY2l0eUBsaXN0cy54ZW5wcm9qZWN0Lm9yZwo+IGh0dHA6Ly9saXN0cy54ZW5wcm9qZWN0 Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vcHVibGljaXR5CgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5IG1haWxpbmcgbGlzdApQ dWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3Jn L2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK From publicity-bounces@lists.xenproject.org Thu May 14 12:34:28 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 12:34:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YssLM-000461-1Z; Thu, 14 May 2015 12:34:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YssLJ-00045V-Vm for publicity@lists.xenproject.org; Thu, 14 May 2015 12:34:26 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 54/BD-03197-05694555; Thu, 14 May 2015 12:34:24 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1431606862!15406064!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27553 invoked from network); 14 May 2015 12:34:22 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 12:34:22 -0000 Received: by wgin8 with SMTP id n8so73915850wgi.0 for ; Thu, 14 May 2015 05:34:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Kb55RxDGdtL1EHiWFm/siFqY0nImHARHKWLX/wpvc9Q=; b=MF7+3mxG+r4qvLZw6qQ+BiCtx/aR8QTTfzbJJ9hPTJWumqu1fdeIMnj1TvGCjp4jHD quRMVHkwni/lx0EhdVxxjBOEniFdOxf5MiGtHNx+6RzQunLcpVNJsC8RaNP1E+kOZBqx rS2KuKSxKVTAsuo++0saDsMek3A/Bn452CUn/yFJICw+tOuIPujFZYYPvGnCpPKtRXCs IavbZU/I4KZsVzuGFBI33U9rlr+tLX3Xq2N7Kv7X5ST15s1Xtotjjnml4VbMFe5oIy3K Ky3rJEx6R1A0iT+HVCqDlKb5MPiGwHHoPt6S3Cowu/JwSxK1++anBJDyYSGmPv+R6ylj DJMQ== X-Gm-Message-State: ALoCoQky5RYSjwtxAaBDtAn2NsFMdKc8TwqCjbE0fQOpADYBt4AfERcXDeXVRSTy6WBB5RjhJ4Oe MIME-Version: 1.0 X-Received: by 10.180.94.39 with SMTP id cz7mr47221093wib.66.1431606862242; Thu, 14 May 2015 05:34:22 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 05:34:22 -0700 (PDT) In-Reply-To: <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> Date: Thu, 14 May 2015 14:34:22 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6774628228176345546==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6774628228176345546== Content-Type: multipart/alternative; boundary=f46d04426de67b7789051609f27c --f46d04426de67b7789051609f27c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2015 at 1:40 PM, Lars Kurth wrote: > Hi folks, > > although a lot of interesting suggestions were raised, I think it is more > helpful to propose concrete text changes or additions, rather than > suggestions which require that the author does additional research. > That would be indeed helpful ;) > > > Also, is it worth mentioning why the qemu stub domain isn't the > default? Is it all compiled and installed in most of the hypervisor > distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qe= mu > stub domains, although that might have changed in the recent release. > > Is there a conclusion or a concrete paragraph on this one that you can > suggest? I did check Ubuntu and a few other distros and they all have stu= b > domains. XenServer may not have. But the domain may of course not be buil= t, > even though the > I suppose any outcome/mention should deb in the "One would think this is = a > complex...." > I'll add a discussion on why stubdoms might not be provided by default - tradeoff between memory usage vs security and the fact that everyone should use it on a given host to gain the extra protection. > @Tamas: > > I would propose to position this as a guest blog post: we normally do thi= s > for someones 1st blog post on xenproject.org. Normally what we do in such > cases is to add a pre-amble. An example is: "This is a guest blog post by > Georg D=C3=B6rn, a long-time system administrator and open source enthusi= ast. > Georg founded his company its-doern in 2008, to develop solutions for > customers entirely from open source software." > > If you could add a brief description that would be great. > Sure. > > > The recent disclosure of the VENOM bug affecting major open-source > hypervisors, such as KVM and Xen, has been circulating in the tech news > lately, causing > how about replacing lately with a date > > many to reevaluate their security posture when using cloud > infrastructures. That is a very good thing indeed. Virtualization and the > cloud has been for too long > I am not sure what you mean by security posture: maybe a more common > phrase would be better or an example. > Ack, I'll just say "reevaluate their risks". > > I also think that some of the more recent Venom articles are partly also > calling out the Venom coverage a clever marketing campaign by CrowdStrike > to raise their profile and it is also now clear that far fewer vendors th= an > originally anticipated are affected by Venom > * > http://www.csoonline.com/article/2922066/vulnerabilities/venom-hype-and-p= re-planned-marketing-campaign-panned-by-experts.html > * > http://gizmodo.com/please-stop-comparing-every-security-flaw-to-heartblee= d-1704259495 > * > http://www.forbes.com/sites/thomasbrewster/2015/05/13/venom-vulnerability= -could-hit-amazon-oracle-rackspace-citrix/ > * > http://www.theregister.co.uk/2015/05/13/heartbleed_eat_your_heart_out_ven= om_vuln_poisons_countless_vms/ > * http://www.zdnet.com/article/venom-the-anti-toxin-is-here/ > I know, that's why I felt it would be good to address this. For those paying attention this is not really news. Yes, it needs to be fixed but it's not like it wasn't anticipated in general.. > > > erroneously considered to be a silver bullet against intrusions, malwar= e > and APTs. > What is an APT? > Marketing buzz word for targeted attacks. I'll cut it ;) > > > The cloud is anything but a safe place. > I am not sure we want to single out the cloud. Maybe, expand the list a > bit, e.g. the "internet and cloud". After all we are no worse than other > software stacks. Maybe we have a better track record than most. > I completely agree but I still want to highlight that the cloud is not bullet proof. Many people just stare at you blankly when it comes to discussing cloud security and why it's needed (in my experience). It raises the bar. It doesn't solve all your problems and can even introduce new ones= . > > > VENOM in that sense is just another one in the long list of > vulnerabilities that seem to be plaguing hypervisors. > Again, maybe not single out hypervisors > As I said, I kind of want to make people aware that hypervisors have problems too. Maybe "plaguing" is a harsh description though ;) > > > However, there are differences between vulnerabilities. While VENOM is > indeed a serious bug and can result in a VM escape, which can compromise > all VMs on > > the host, it doesn=E2=80=99t have to be. In fact, VENOM-style attacks h= ave been > known for a long time. And there are easy-to-deploy co > > unter-measures to mitigate the risk of such exploits, natively availabl= e > in Xen and KVM. > Are there ways to mitigate this for KVM? When I read this I was expecting > to read about KVM also. So maybe drop KVM here, as it feels like a loose > ends. > Actually re-reading this again, you do mention KVM sVirt SELinux policies= : > it's easy to miss because that paragraph is embedded into a longer sectio= n > about stub domains. Maybe add something immediately afterwards along the > lines of "Xen provides subdomains to sandbox VENOM style exploits in a > de-priviledged domaon and KVM allows for similar jailing of the QEMU > process via the native SELinux sVirt policies." > > Yea, that makes sense. Red Hat already posted a blog entry saying sVirt protects against this. > > While modern systems come ... > > Devices such as your network card, graphics card and your hard drive. > While Linux comes with paravirtual (virtualization-aware) drivers to crea= te > such devices, > > emulation is often the only solution to run operating > systems that do not have such kernel drivers. This has been traditionally > the case with Windows. This > > emulation layer has been implemented in QEMU, which has caused VENOM an= d > a handful of other VM-escape bugs in recent years > Maybe list some examples re QEMU related VM-escaped bugs > Sure. > I think it is worth pointing pout that people use PVHVM (HVM) for > performance reasons also. One gets the impression from this paragraph tha= t > the only reason > Ack. > > Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM > escape attack against KVM, through QEMU. > Link? > > I have a set of footnotes with links that didn't copy in the original email. I'll copy those too in the next revision. > > As a sidenote, KVM allows for similar jailing of the QEMU process via > the native SELinux sVirt policies. > See above > > > One would think it is a complex process to take advantage of this > protection, > Maybe link to http://wiki.xenproject.org/wiki/Device_Model_Stub_Domains > Yeap, had the link in a footnote. > > Unfortunately, your cloud provider may not allow you to enable this > option. > You should probably also call out distros > > Regards > Lars > > Thanks, Tamas > > On 14 May 2015, at 11:59, Stefano Stabellini < > stefano.stabellini@eu.citrix.com> wrote: > > > > On Thu, 14 May 2015, George Dunlap wrote: > >> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > >>> Yeah... it's worth noting that unikernels like MirageOS or HaLVM neve= r > use the x86 device emulation and so require a far easier to audit > hypervisor TCB that doesn't involve qemu. > >>> > >>> Also, is it worth mentioning why the qemu stub domain isn't the > default? Is it all compiled and installed in most of the hypervisor > distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qe= mu > stub domains, although that might have changed in the recent release. > >> > >> Well the main reason is that qemu-upstream doesn't work with stub > >> domains yet. Anthony worked on it for what, a year? He got pretty fa= r > >> but there are just a lot of thorny issues to deal with. > > > > To be fair, there are also other reasons: memory overhead, number of > > domains doubling, and the additional complexity of having 2 QEMUs for > > each domain (there is still one QEMU in Dom0 running for each guest, > > although it just provides the PV backends). > > > > _______________________________________________ > > Publicity mailing list > > Publicity@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --f46d04426de67b7789051609f27c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 14, 2015 at 1:40 PM, Lars Kurth <lars.kurth.xen@gma= il.com> wrote:
Hi folks,
although a lot of interesting suggestions were raised, I think it is more h= elpful to propose concrete text changes or additions, rather than suggestio= ns which require that the author does additional research.
=

That would be indeed helpful ;)
=C2=A0

> Also, is it worth mentioning why the qemu stub domain isn't the de= fault?=C2=A0 Is it all compiled and installed in most of the hypervisor dis= tributions on Ubuntu/CentOS/etc?=C2=A0 I don't think even XenServer use= s qemu stub domains, although that might have changed in the recent release= .

Is there a conclusion or a concrete paragraph on this one that you c= an suggest? I did check Ubuntu and a few other distros and they all have st= ub domains. XenServer may not have. But the domain may of course not be bui= lt, even though the
I suppose any outcome/mention should deb in the "One would think this = is a complex...."

I'll add a d= iscussion on why stubdoms might not be provided by default - tradeoff betwe= en memory usage vs security and the fact that everyone should use it on a g= iven host to gain the extra protection.
=C2=A0
@Tamas:

I would propose to position this as a guest blog post: we normally do this = for someones 1st blog post on xenproject.org. Normally what we do in such cases is to add a pr= e-amble. An example is: "This is a guest blog post by Georg D=C3=B6rn,= a long-time system administrator and open source enthusiast. Georg founded= his company its-doern in 2008, to develop solutions for customers entirely= from open source software."

If you could add a brief description that would be great.
<= div>
Sure.
=C2=A0

> The recent disclosure of the VENOM bug affecting major open-source hyp= ervisors, such as KVM and Xen, has been circulating in the tech news lately= , causing
how about replacing lately with a date
> many to reevaluate their security posture when using cloud infra= structures. That is a very good thing indeed. Virtualization and the cloud = has been for too long
I am not sure what you mean by security posture: maybe a more common= phrase would be better or an example.

= Ack, I'll just say "reevaluate their risks".
= =C2=A0

I also think that some of the more recent Venom articles are partly also ca= lling out the Venom coverage a clever marketing campaign by CrowdStrike to = raise their profile and it is also now clear that far fewer vendors than or= iginally anticipated are affected by Venom
* http://www.csoonline.com/article/2922066/vulnerabilities/venom-hype= -and-pre-planned-marketing-campaign-panned-by-experts.html
* http://gizmodo.com/please-stop-c= omparing-every-security-flaw-to-heartbleed-1704259495
* ht= tp://www.forbes.com/sites/thomasbrewster/2015/05/13/venom-vulnerability-cou= ld-hit-amazon-oracle-rackspace-citrix/
* http://www.the= register.co.uk/2015/05/13/heartbleed_eat_your_heart_out_venom_vuln_poisons_= countless_vms/
* http://www.zdnet.com/article/venom-the-anti-toxin-is-here/<= /a>


> erroneously considered to be a silver bullet against intrusions, malwa= re and APTs.
What is an APT?


> The cloud is anything but a safe place.
I am not sure we want to single out the cloud. Maybe, expand the lis= t a bit, e.g. the "internet and cloud". After all we are no worse= than other software stacks. Maybe we have a better track record than most.=

I completely agree bu= t I still want to highlight that the cloud is not bullet proof. Many people= just stare at you blankly when it comes to discussing cloud security and w= hy it's needed (in my experience). It raises the bar. It doesn't so= lve all your problems and can even introduce new ones.

> VENOM in that sense is just another one in the long list of vulnerabil= ities that seem to be plaguing hypervisors.
Again, maybe not single out hypervisors

As I said, I kind of want to make people aware that hypervisors hav= e problems too. Maybe "plaguing" is a harsh description though ;)=
=C2=A0

> However, there are differences between vulnerabilities. While VENOM is= indeed a serious bug and can result in a VM escape, which can compromise a= ll VMs on
> the host, it doesn=E2=80=99t have to be. In fact, VENOM-style attacks = have been known for a long time. And there are easy-to-deploy co
> unter-measures to mitigate the risk of such exploits, natively availab= le in Xen and KVM.
Are there ways to mitigate this for KVM? When I read this I was expe= cting to read about KVM also. So maybe drop KVM here, as it feels like a lo= ose ends.
Actually re-reading this again, you do mention KVM sVirt SELinux policies: = it's easy to miss because that paragraph is embedded into a longer sect= ion about stub domains. Maybe add something immediately afterwards along th= e lines of "Xen provides subdomains to sandbox VENOM style exploits in= a de-priviledged domaon and KVM allows for similar jailing of the QEMU pro= cess via the native SELinux sVirt policies."


Yea, that makes sense. Red Hat already= posted a blog entry saying sVirt protects against this.
=C2= =A0
> While modern systems come ...
> Devices such as your network card, graphics card and your hard d= rive. While Linux comes with paravirtual (virtualization-aware) drivers to = create such devices, > > emulation is often the only solution to run = operating systems that do not have such kernel drivers. This has been tradi= tionally the case with Windows. This
> emulation layer has been implemented in QEMU, which has caused VENOM a= nd a handful of other VM-escape bugs in recent years
Maybe list some examples re QEMU related VM-escaped bugs

Sure.
=C2=A0
I think it is worth pointing pout that people use PVHVM (HVM) for performan= ce reasons also. One gets the impression from this paragraph that the only = reason

Ack.
= =C2=A0
> Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM es= cape attack against KVM, through QEMU.
Link?


I have a set of footnotes= with links that didn't copy in the original email. I'll copy those= too in the next revision.
=C2=A0
> As a sidenote, KVM allows for similar jailing of the QEMU process via = the native SELinux sVirt policies.
See above

> One would think it is a complex process to take advantage of this prot= ection,
Maybe link to http://wiki.xenproject.org/wiki/Device_Mo= del_Stub_Domains

Yeap,= had the link in a footnote.
=C2=A0
> Unfortunately, your cloud provider may not allow you to enable this op= tion.
You should probably also call out distros

Regards
Lars


Thanks,
=
Tamas
=C2=A0
<= span> > On 14 May 2015, at 11:59, Stefano Stabellini <stefano.stabellini@eu.citr= ix.com> wrote:
>
> On Thu, 14 May 2015, George Dunlap wrote:
>> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote:
>>> Yeah... it's worth noting that unikernels like MirageOS or= HaLVM never use the x86 device emulation and so require a far easier to au= dit hypervisor TCB that doesn't involve qemu.
>>>
>>> Also, is it worth mentioning why the qemu stub domain isn'= t the default?=C2=A0 Is it all compiled and installed in most of the hyperv= isor distributions on Ubuntu/CentOS/etc?=C2=A0 I don't think even XenSe= rver uses qemu stub domains, although that might have changed in the recent= release.
>>
>> Well the main reason is that qemu-upstream doesn't work with s= tub
>> domains yet.=C2=A0 Anthony worked on it for what, a year?=C2=A0 He= got pretty far
>> but there are just a lot of thorny issues to deal with.
>
> To be fair, there are also other reasons: memory overhead, number of > domains doubling, and the additional complexity of having 2 QEMUs for<= br> > each domain (there is still one QEMU in Dom0 running for each guest, > although it just provides the PV backends).
>
> _______________________________________________<= br> > Publicity mailing list
> Pu= blicity@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo= /publicity




--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--f46d04426de67b7789051609f27c-- --===============6774628228176345546== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6774628228176345546==-- From publicity-bounces@lists.xenproject.org Thu May 14 12:34:28 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 12:34:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YssLM-000461-1Z; Thu, 14 May 2015 12:34:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YssLJ-00045V-Vm for publicity@lists.xenproject.org; Thu, 14 May 2015 12:34:26 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 54/BD-03197-05694555; Thu, 14 May 2015 12:34:24 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1431606862!15406064!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27553 invoked from network); 14 May 2015 12:34:22 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 12:34:22 -0000 Received: by wgin8 with SMTP id n8so73915850wgi.0 for ; Thu, 14 May 2015 05:34:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Kb55RxDGdtL1EHiWFm/siFqY0nImHARHKWLX/wpvc9Q=; b=MF7+3mxG+r4qvLZw6qQ+BiCtx/aR8QTTfzbJJ9hPTJWumqu1fdeIMnj1TvGCjp4jHD quRMVHkwni/lx0EhdVxxjBOEniFdOxf5MiGtHNx+6RzQunLcpVNJsC8RaNP1E+kOZBqx rS2KuKSxKVTAsuo++0saDsMek3A/Bn452CUn/yFJICw+tOuIPujFZYYPvGnCpPKtRXCs IavbZU/I4KZsVzuGFBI33U9rlr+tLX3Xq2N7Kv7X5ST15s1Xtotjjnml4VbMFe5oIy3K Ky3rJEx6R1A0iT+HVCqDlKb5MPiGwHHoPt6S3Cowu/JwSxK1++anBJDyYSGmPv+R6ylj DJMQ== X-Gm-Message-State: ALoCoQky5RYSjwtxAaBDtAn2NsFMdKc8TwqCjbE0fQOpADYBt4AfERcXDeXVRSTy6WBB5RjhJ4Oe MIME-Version: 1.0 X-Received: by 10.180.94.39 with SMTP id cz7mr47221093wib.66.1431606862242; Thu, 14 May 2015 05:34:22 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 05:34:22 -0700 (PDT) In-Reply-To: <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> Date: Thu, 14 May 2015 14:34:22 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6774628228176345546==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6774628228176345546== Content-Type: multipart/alternative; boundary=f46d04426de67b7789051609f27c --f46d04426de67b7789051609f27c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2015 at 1:40 PM, Lars Kurth wrote: > Hi folks, > > although a lot of interesting suggestions were raised, I think it is more > helpful to propose concrete text changes or additions, rather than > suggestions which require that the author does additional research. > That would be indeed helpful ;) > > > Also, is it worth mentioning why the qemu stub domain isn't the > default? Is it all compiled and installed in most of the hypervisor > distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qe= mu > stub domains, although that might have changed in the recent release. > > Is there a conclusion or a concrete paragraph on this one that you can > suggest? I did check Ubuntu and a few other distros and they all have stu= b > domains. XenServer may not have. But the domain may of course not be buil= t, > even though the > I suppose any outcome/mention should deb in the "One would think this is = a > complex...." > I'll add a discussion on why stubdoms might not be provided by default - tradeoff between memory usage vs security and the fact that everyone should use it on a given host to gain the extra protection. > @Tamas: > > I would propose to position this as a guest blog post: we normally do thi= s > for someones 1st blog post on xenproject.org. Normally what we do in such > cases is to add a pre-amble. An example is: "This is a guest blog post by > Georg D=C3=B6rn, a long-time system administrator and open source enthusi= ast. > Georg founded his company its-doern in 2008, to develop solutions for > customers entirely from open source software." > > If you could add a brief description that would be great. > Sure. > > > The recent disclosure of the VENOM bug affecting major open-source > hypervisors, such as KVM and Xen, has been circulating in the tech news > lately, causing > how about replacing lately with a date > > many to reevaluate their security posture when using cloud > infrastructures. That is a very good thing indeed. Virtualization and the > cloud has been for too long > I am not sure what you mean by security posture: maybe a more common > phrase would be better or an example. > Ack, I'll just say "reevaluate their risks". > > I also think that some of the more recent Venom articles are partly also > calling out the Venom coverage a clever marketing campaign by CrowdStrike > to raise their profile and it is also now clear that far fewer vendors th= an > originally anticipated are affected by Venom > * > http://www.csoonline.com/article/2922066/vulnerabilities/venom-hype-and-p= re-planned-marketing-campaign-panned-by-experts.html > * > http://gizmodo.com/please-stop-comparing-every-security-flaw-to-heartblee= d-1704259495 > * > http://www.forbes.com/sites/thomasbrewster/2015/05/13/venom-vulnerability= -could-hit-amazon-oracle-rackspace-citrix/ > * > http://www.theregister.co.uk/2015/05/13/heartbleed_eat_your_heart_out_ven= om_vuln_poisons_countless_vms/ > * http://www.zdnet.com/article/venom-the-anti-toxin-is-here/ > I know, that's why I felt it would be good to address this. For those paying attention this is not really news. Yes, it needs to be fixed but it's not like it wasn't anticipated in general.. > > > erroneously considered to be a silver bullet against intrusions, malwar= e > and APTs. > What is an APT? > Marketing buzz word for targeted attacks. I'll cut it ;) > > > The cloud is anything but a safe place. > I am not sure we want to single out the cloud. Maybe, expand the list a > bit, e.g. the "internet and cloud". After all we are no worse than other > software stacks. Maybe we have a better track record than most. > I completely agree but I still want to highlight that the cloud is not bullet proof. Many people just stare at you blankly when it comes to discussing cloud security and why it's needed (in my experience). It raises the bar. It doesn't solve all your problems and can even introduce new ones= . > > > VENOM in that sense is just another one in the long list of > vulnerabilities that seem to be plaguing hypervisors. > Again, maybe not single out hypervisors > As I said, I kind of want to make people aware that hypervisors have problems too. Maybe "plaguing" is a harsh description though ;) > > > However, there are differences between vulnerabilities. While VENOM is > indeed a serious bug and can result in a VM escape, which can compromise > all VMs on > > the host, it doesn=E2=80=99t have to be. In fact, VENOM-style attacks h= ave been > known for a long time. And there are easy-to-deploy co > > unter-measures to mitigate the risk of such exploits, natively availabl= e > in Xen and KVM. > Are there ways to mitigate this for KVM? When I read this I was expecting > to read about KVM also. So maybe drop KVM here, as it feels like a loose > ends. > Actually re-reading this again, you do mention KVM sVirt SELinux policies= : > it's easy to miss because that paragraph is embedded into a longer sectio= n > about stub domains. Maybe add something immediately afterwards along the > lines of "Xen provides subdomains to sandbox VENOM style exploits in a > de-priviledged domaon and KVM allows for similar jailing of the QEMU > process via the native SELinux sVirt policies." > > Yea, that makes sense. Red Hat already posted a blog entry saying sVirt protects against this. > > While modern systems come ... > > Devices such as your network card, graphics card and your hard drive. > While Linux comes with paravirtual (virtualization-aware) drivers to crea= te > such devices, > > emulation is often the only solution to run operating > systems that do not have such kernel drivers. This has been traditionally > the case with Windows. This > > emulation layer has been implemented in QEMU, which has caused VENOM an= d > a handful of other VM-escape bugs in recent years > Maybe list some examples re QEMU related VM-escaped bugs > Sure. > I think it is worth pointing pout that people use PVHVM (HVM) for > performance reasons also. One gets the impression from this paragraph tha= t > the only reason > Ack. > > Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM > escape attack against KVM, through QEMU. > Link? > > I have a set of footnotes with links that didn't copy in the original email. I'll copy those too in the next revision. > > As a sidenote, KVM allows for similar jailing of the QEMU process via > the native SELinux sVirt policies. > See above > > > One would think it is a complex process to take advantage of this > protection, > Maybe link to http://wiki.xenproject.org/wiki/Device_Model_Stub_Domains > Yeap, had the link in a footnote. > > Unfortunately, your cloud provider may not allow you to enable this > option. > You should probably also call out distros > > Regards > Lars > > Thanks, Tamas > > On 14 May 2015, at 11:59, Stefano Stabellini < > stefano.stabellini@eu.citrix.com> wrote: > > > > On Thu, 14 May 2015, George Dunlap wrote: > >> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote: > >>> Yeah... it's worth noting that unikernels like MirageOS or HaLVM neve= r > use the x86 device emulation and so require a far easier to audit > hypervisor TCB that doesn't involve qemu. > >>> > >>> Also, is it worth mentioning why the qemu stub domain isn't the > default? Is it all compiled and installed in most of the hypervisor > distributions on Ubuntu/CentOS/etc? I don't think even XenServer uses qe= mu > stub domains, although that might have changed in the recent release. > >> > >> Well the main reason is that qemu-upstream doesn't work with stub > >> domains yet. Anthony worked on it for what, a year? He got pretty fa= r > >> but there are just a lot of thorny issues to deal with. > > > > To be fair, there are also other reasons: memory overhead, number of > > domains doubling, and the additional complexity of having 2 QEMUs for > > each domain (there is still one QEMU in Dom0 running for each guest, > > although it just provides the PV backends). > > > > _______________________________________________ > > Publicity mailing list > > Publicity@lists.xenproject.org > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --f46d04426de67b7789051609f27c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 14, 2015 at 1:40 PM, Lars Kurth <lars.kurth.xen@gma= il.com> wrote:
Hi folks,
although a lot of interesting suggestions were raised, I think it is more h= elpful to propose concrete text changes or additions, rather than suggestio= ns which require that the author does additional research.
=

That would be indeed helpful ;)
=C2=A0

> Also, is it worth mentioning why the qemu stub domain isn't the de= fault?=C2=A0 Is it all compiled and installed in most of the hypervisor dis= tributions on Ubuntu/CentOS/etc?=C2=A0 I don't think even XenServer use= s qemu stub domains, although that might have changed in the recent release= .

Is there a conclusion or a concrete paragraph on this one that you c= an suggest? I did check Ubuntu and a few other distros and they all have st= ub domains. XenServer may not have. But the domain may of course not be bui= lt, even though the
I suppose any outcome/mention should deb in the "One would think this = is a complex...."

I'll add a d= iscussion on why stubdoms might not be provided by default - tradeoff betwe= en memory usage vs security and the fact that everyone should use it on a g= iven host to gain the extra protection.
=C2=A0
@Tamas:

I would propose to position this as a guest blog post: we normally do this = for someones 1st blog post on xenproject.org. Normally what we do in such cases is to add a pr= e-amble. An example is: "This is a guest blog post by Georg D=C3=B6rn,= a long-time system administrator and open source enthusiast. Georg founded= his company its-doern in 2008, to develop solutions for customers entirely= from open source software."

If you could add a brief description that would be great.
<= div>
Sure.
=C2=A0

> The recent disclosure of the VENOM bug affecting major open-source hyp= ervisors, such as KVM and Xen, has been circulating in the tech news lately= , causing
how about replacing lately with a date
> many to reevaluate their security posture when using cloud infra= structures. That is a very good thing indeed. Virtualization and the cloud = has been for too long
I am not sure what you mean by security posture: maybe a more common= phrase would be better or an example.

= Ack, I'll just say "reevaluate their risks".
= =C2=A0

I also think that some of the more recent Venom articles are partly also ca= lling out the Venom coverage a clever marketing campaign by CrowdStrike to = raise their profile and it is also now clear that far fewer vendors than or= iginally anticipated are affected by Venom
* http://www.csoonline.com/article/2922066/vulnerabilities/venom-hype= -and-pre-planned-marketing-campaign-panned-by-experts.html
* http://gizmodo.com/please-stop-c= omparing-every-security-flaw-to-heartbleed-1704259495
* ht= tp://www.forbes.com/sites/thomasbrewster/2015/05/13/venom-vulnerability-cou= ld-hit-amazon-oracle-rackspace-citrix/
* http://www.the= register.co.uk/2015/05/13/heartbleed_eat_your_heart_out_venom_vuln_poisons_= countless_vms/
* http://www.zdnet.com/article/venom-the-anti-toxin-is-here/<= /a>


> erroneously considered to be a silver bullet against intrusions, malwa= re and APTs.
What is an APT?


> The cloud is anything but a safe place.
I am not sure we want to single out the cloud. Maybe, expand the lis= t a bit, e.g. the "internet and cloud". After all we are no worse= than other software stacks. Maybe we have a better track record than most.=

I completely agree bu= t I still want to highlight that the cloud is not bullet proof. Many people= just stare at you blankly when it comes to discussing cloud security and w= hy it's needed (in my experience). It raises the bar. It doesn't so= lve all your problems and can even introduce new ones.

> VENOM in that sense is just another one in the long list of vulnerabil= ities that seem to be plaguing hypervisors.
Again, maybe not single out hypervisors

As I said, I kind of want to make people aware that hypervisors hav= e problems too. Maybe "plaguing" is a harsh description though ;)=
=C2=A0

> However, there are differences between vulnerabilities. While VENOM is= indeed a serious bug and can result in a VM escape, which can compromise a= ll VMs on
> the host, it doesn=E2=80=99t have to be. In fact, VENOM-style attacks = have been known for a long time. And there are easy-to-deploy co
> unter-measures to mitigate the risk of such exploits, natively availab= le in Xen and KVM.
Are there ways to mitigate this for KVM? When I read this I was expe= cting to read about KVM also. So maybe drop KVM here, as it feels like a lo= ose ends.
Actually re-reading this again, you do mention KVM sVirt SELinux policies: = it's easy to miss because that paragraph is embedded into a longer sect= ion about stub domains. Maybe add something immediately afterwards along th= e lines of "Xen provides subdomains to sandbox VENOM style exploits in= a de-priviledged domaon and KVM allows for similar jailing of the QEMU pro= cess via the native SELinux sVirt policies."


Yea, that makes sense. Red Hat already= posted a blog entry saying sVirt protects against this.
=C2= =A0
> While modern systems come ...
> Devices such as your network card, graphics card and your hard d= rive. While Linux comes with paravirtual (virtualization-aware) drivers to = create such devices, > > emulation is often the only solution to run = operating systems that do not have such kernel drivers. This has been tradi= tionally the case with Windows. This
> emulation layer has been implemented in QEMU, which has caused VENOM a= nd a handful of other VM-escape bugs in recent years
Maybe list some examples re QEMU related VM-escaped bugs

Sure.
=C2=A0
I think it is worth pointing pout that people use PVHVM (HVM) for performan= ce reasons also. One gets the impression from this paragraph that the only = reason

Ack.
= =C2=A0
> Back in 2011, the Blackhat talk on Virtunoid demonstrated such a VM es= cape attack against KVM, through QEMU.
Link?


I have a set of footnotes= with links that didn't copy in the original email. I'll copy those= too in the next revision.
=C2=A0
> As a sidenote, KVM allows for similar jailing of the QEMU process via = the native SELinux sVirt policies.
See above

> One would think it is a complex process to take advantage of this prot= ection,
Maybe link to http://wiki.xenproject.org/wiki/Device_Mo= del_Stub_Domains

Yeap,= had the link in a footnote.
=C2=A0
> Unfortunately, your cloud provider may not allow you to enable this op= tion.
You should probably also call out distros

Regards
Lars


Thanks,
=
Tamas
=C2=A0
<= span> > On 14 May 2015, at 11:59, Stefano Stabellini <stefano.stabellini@eu.citr= ix.com> wrote:
>
> On Thu, 14 May 2015, George Dunlap wrote:
>> On 05/14/2015 11:39 AM, Anil Madhavapeddy wrote:
>>> Yeah... it's worth noting that unikernels like MirageOS or= HaLVM never use the x86 device emulation and so require a far easier to au= dit hypervisor TCB that doesn't involve qemu.
>>>
>>> Also, is it worth mentioning why the qemu stub domain isn'= t the default?=C2=A0 Is it all compiled and installed in most of the hyperv= isor distributions on Ubuntu/CentOS/etc?=C2=A0 I don't think even XenSe= rver uses qemu stub domains, although that might have changed in the recent= release.
>>
>> Well the main reason is that qemu-upstream doesn't work with s= tub
>> domains yet.=C2=A0 Anthony worked on it for what, a year?=C2=A0 He= got pretty far
>> but there are just a lot of thorny issues to deal with.
>
> To be fair, there are also other reasons: memory overhead, number of > domains doubling, and the additional complexity of having 2 QEMUs for<= br> > each domain (there is still one QEMU in Dom0 running for each guest, > although it just provides the PV backends).
>
> _______________________________________________<= br> > Publicity mailing list
> Pu= blicity@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo= /publicity




--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--f46d04426de67b7789051609f27c-- --===============6774628228176345546== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6774628228176345546==-- From publicity-bounces@lists.xenproject.org Thu May 14 12:59:55 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 12:59:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yssjx-0006HN-UT; Thu, 14 May 2015 12:59:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yssjx-0006HH-Bn for publicity@lists.xenproject.org; Thu, 14 May 2015 12:59:53 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 8F/AF-03202-84C94555; Thu, 14 May 2015 12:59:52 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1431608390!17565584!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22783 invoked from network); 14 May 2015 12:59:51 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 12:59:51 -0000 Received: by wgnd10 with SMTP id d10so72230513wgn.2 for ; Thu, 14 May 2015 05:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GqTanY1zJ1dVoeeixvIya4dEzaZd3GuWKNZYqLjtKu4=; b=ySgQh50gS5WCD99SuxqYS9Gb8nlHJs3XADfGCbrqs84jxoYgNNUGFztvwp3b1dXdnG UjhlbIXts683kjA3DgJa/E5M0uKhe47dUTJENT/rL1TxX1IhCwwH1fjH2Q0tdkIVHreU 4u+4xN3SdV4hjr8nB8v8mn5w64aT4yhvJgKHjdoZDwBdmpG0MgpIFLUW2xCb6bMs77uW WXalAoAocEioRFZvqeN2IEXguX0agK/b1czo2dPpbU7PTPu1DnldGvGHFG70QV9eMroh A3E38EbI1z4Gc/NFyOIzdfpKtrSVg8DRzcZtiiR+A4vIo3A0Zt1YJsdNUiX0L1Yd/Tzq c+VQ== X-Received: by 10.194.79.199 with SMTP id l7mr7823975wjx.158.1431608390505; Thu, 14 May 2015 05:59:50 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id n1sm13210792wix.0.2015.05.14.05.59.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 05:59:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 13:59:47 +0100 Message-Id: <97D4885D-7EB4-492E-8665-C37D0F777208@gmail.com> References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6692007142158113601==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6692007142158113601== Content-Type: multipart/alternative; boundary="Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102" --Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14 May 2015, at 13:34, Lengyel, Tamas wrote: >=20 > > The cloud is anything but a safe place. > I am not sure we want to single out the cloud. Maybe, expand the list = a bit, e.g. the "internet and cloud". After all we are no worse than = other software stacks. Maybe we have a better track record than most. >=20 > I completely agree but I still want to highlight that the cloud is not = bullet proof. Many people just stare at you blankly when it comes to = discussing cloud security and why it's needed (in my experience). It = raises the bar. It doesn't solve all your problems and can even = introduce new ones. > =20 >=20 > > VENOM in that sense is just another one in the long list of = vulnerabilities that seem to be plaguing hypervisors. > Again, maybe not single out hypervisors >=20 > As I said, I kind of want to make people aware that hypervisors have = problems too. Maybe "plaguing" is a harsh description though ;) I think in that case, why don't you be more general at first and zoom in = on your point. I do agree that "plaguing" is harsh Otherwise looking forward to the next version Lars= --Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 14 May 2015, at 13:34, Lengyel, Tamas <tlengyel@novetta.com> wrote:

> The cloud is anything but a safe place.
I am not sure we want to single out the cloud. Maybe, = expand the list a bit, e.g. the "internet and cloud". After all we are = no worse than other software stacks. Maybe we have a better track record = than most.

I = completely agree but I still want to highlight that the cloud is not = bullet proof. Many people just stare at you blankly when it comes to = discussing cloud security and why it's needed (in my experience). It = raises the bar. It doesn't solve all your problems and can even = introduce new ones.
 

> VENOM in that sense is just another one = in the long list of vulnerabilities that seem to be plaguing = hypervisors.
Again, maybe not single out = hypervisors

As I said, I kind of want to make = people aware that hypervisors have problems too. Maybe "plaguing" is a = harsh description though ;)

I = think in that case, why don't you be more general at first and zoom in = on your point. I do agree that "plaguing" is harsh

Otherwise looking forward to the next = version
Lars
= --Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102-- --===============6692007142158113601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6692007142158113601==-- From publicity-bounces@lists.xenproject.org Thu May 14 12:59:55 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 12:59:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yssjx-0006HN-UT; Thu, 14 May 2015 12:59:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yssjx-0006HH-Bn for publicity@lists.xenproject.org; Thu, 14 May 2015 12:59:53 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 8F/AF-03202-84C94555; Thu, 14 May 2015 12:59:52 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1431608390!17565584!1 X-Originating-IP: [74.125.82.54] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22783 invoked from network); 14 May 2015 12:59:51 -0000 Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 12:59:51 -0000 Received: by wgnd10 with SMTP id d10so72230513wgn.2 for ; Thu, 14 May 2015 05:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GqTanY1zJ1dVoeeixvIya4dEzaZd3GuWKNZYqLjtKu4=; b=ySgQh50gS5WCD99SuxqYS9Gb8nlHJs3XADfGCbrqs84jxoYgNNUGFztvwp3b1dXdnG UjhlbIXts683kjA3DgJa/E5M0uKhe47dUTJENT/rL1TxX1IhCwwH1fjH2Q0tdkIVHreU 4u+4xN3SdV4hjr8nB8v8mn5w64aT4yhvJgKHjdoZDwBdmpG0MgpIFLUW2xCb6bMs77uW WXalAoAocEioRFZvqeN2IEXguX0agK/b1czo2dPpbU7PTPu1DnldGvGHFG70QV9eMroh A3E38EbI1z4Gc/NFyOIzdfpKtrSVg8DRzcZtiiR+A4vIo3A0Zt1YJsdNUiX0L1Yd/Tzq c+VQ== X-Received: by 10.194.79.199 with SMTP id l7mr7823975wjx.158.1431608390505; Thu, 14 May 2015 05:59:50 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id n1sm13210792wix.0.2015.05.14.05.59.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 05:59:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 13:59:47 +0100 Message-Id: <97D4885D-7EB4-492E-8665-C37D0F777208@gmail.com> References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6692007142158113601==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6692007142158113601== Content-Type: multipart/alternative; boundary="Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102" --Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14 May 2015, at 13:34, Lengyel, Tamas wrote: >=20 > > The cloud is anything but a safe place. > I am not sure we want to single out the cloud. Maybe, expand the list = a bit, e.g. the "internet and cloud". After all we are no worse than = other software stacks. Maybe we have a better track record than most. >=20 > I completely agree but I still want to highlight that the cloud is not = bullet proof. Many people just stare at you blankly when it comes to = discussing cloud security and why it's needed (in my experience). It = raises the bar. It doesn't solve all your problems and can even = introduce new ones. > =20 >=20 > > VENOM in that sense is just another one in the long list of = vulnerabilities that seem to be plaguing hypervisors. > Again, maybe not single out hypervisors >=20 > As I said, I kind of want to make people aware that hypervisors have = problems too. Maybe "plaguing" is a harsh description though ;) I think in that case, why don't you be more general at first and zoom in = on your point. I do agree that "plaguing" is harsh Otherwise looking forward to the next version Lars= --Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 14 May 2015, at 13:34, Lengyel, Tamas <tlengyel@novetta.com> wrote:

> The cloud is anything but a safe place.
I am not sure we want to single out the cloud. Maybe, = expand the list a bit, e.g. the "internet and cloud". After all we are = no worse than other software stacks. Maybe we have a better track record = than most.

I = completely agree but I still want to highlight that the cloud is not = bullet proof. Many people just stare at you blankly when it comes to = discussing cloud security and why it's needed (in my experience). It = raises the bar. It doesn't solve all your problems and can even = introduce new ones.
 

> VENOM in that sense is just another one = in the long list of vulnerabilities that seem to be plaguing = hypervisors.
Again, maybe not single out = hypervisors

As I said, I kind of want to make = people aware that hypervisors have problems too. Maybe "plaguing" is a = harsh description though ;)

I = think in that case, why don't you be more general at first and zoom in = on your point. I do agree that "plaguing" is harsh

Otherwise looking forward to the next = version
Lars
= --Apple-Mail=_311F32D9-4165-4C23-8041-0C89E030B102-- --===============6692007142158113601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6692007142158113601==-- From publicity-bounces@lists.xenproject.org Thu May 14 13:19:46 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 13:19:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yst3C-0007re-0x; Thu, 14 May 2015 13:19:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yst3B-0007r4-4G for publicity@lists.xenproject.org; Thu, 14 May 2015 13:19:45 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id 87/23-03026-0F0A4555; Thu, 14 May 2015 13:19:44 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1431609583!12062313!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=1.7 required=7.0 tests=HTML_IMAGE_ONLY_32, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3894 invoked from network); 14 May 2015 13:19:43 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 13:19:43 -0000 Received: by wicmx19 with SMTP id mx19so16365289wic.0 for ; Thu, 14 May 2015 06:19:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lWKmSi2Iwd/GMItYnv3SVoXeuZ2/xrhnDYZ80JRPa34=; b=Rbgvz1ql5u8+/72q02Q7e5zqOuwVQlYeW2FJO2M8t/jYZSIMCdvVjY9bAQUL6Yex8F YZU77D8XnWqSCeWoKr55+nbfNA6whhKBw+mTtwWrHX4RPmniMzbSEUE3dtg6mzk0OJnm LeuZW8Fiju+evy8mA65rLpUIqJAoKALP0UctpvzbEYvVJ4sQ2Nf/SQ1KLxAvAClgbPwV Y7XvvB+pdkjLhB1CTDa6+F+T2YgVwgEEMP7OXRNdfDHJL0B+LUoZMZCdNixFOjXRsxEt /2SvHgWqmV/3aQmacEi5O5Js4Qf1236Oisez4bsj7UdCz+9Lz7IFplBrxaf8djdby5QI 43Ng== X-Gm-Message-State: ALoCoQknWOSC/citiwZhdRI6uJWT2zO60cFBL6NfDS/pdRDBIXPBg+5F/KPpUMso3D/AuXz5ge+v MIME-Version: 1.0 X-Received: by 10.194.110.67 with SMTP id hy3mr8212364wjb.87.1431609582917; Thu, 14 May 2015 06:19:42 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 06:19:42 -0700 (PDT) In-Reply-To: References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> Date: Thu, 14 May 2015 15:19:42 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7600058166511092792==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============7600058166511092792== Content-Type: multipart/alternative; boundary=089e010d8292a5ae9505160a9478 --089e010d8292a5ae9505160a9478 Content-Type: text/plain; charset=UTF-8 > > I think it is worth pointing pout that people use PVHVM (HVM) for >> performance reasons also. One gets the impression from this paragraph that >> the only reason >> > > Ack. > > Actually, I think this segways a lot from the origin discussion and people may not necessarily know the difference between PVHVM/PVH/PV/HVM to follow.. -- [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --089e010d8292a5ae9505160a9478 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
=
I think it is worth pointing pout that people use PVHVM (HVM) for performan= ce reasons also. One gets the impression from this paragraph that the only = reason

Ack.


Actu= ally, I think this segways a lot from the origin discussion and people may = not necessarily know the difference between PVHVM/PVH/PV/HVM to follow..

--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--089e010d8292a5ae9505160a9478-- --===============7600058166511092792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============7600058166511092792==-- From publicity-bounces@lists.xenproject.org Thu May 14 13:19:46 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 13:19:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yst3C-0007re-0x; Thu, 14 May 2015 13:19:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yst3B-0007r4-4G for publicity@lists.xenproject.org; Thu, 14 May 2015 13:19:45 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id 87/23-03026-0F0A4555; Thu, 14 May 2015 13:19:44 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1431609583!12062313!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=1.7 required=7.0 tests=HTML_IMAGE_ONLY_32, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3894 invoked from network); 14 May 2015 13:19:43 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 13:19:43 -0000 Received: by wicmx19 with SMTP id mx19so16365289wic.0 for ; Thu, 14 May 2015 06:19:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lWKmSi2Iwd/GMItYnv3SVoXeuZ2/xrhnDYZ80JRPa34=; b=Rbgvz1ql5u8+/72q02Q7e5zqOuwVQlYeW2FJO2M8t/jYZSIMCdvVjY9bAQUL6Yex8F YZU77D8XnWqSCeWoKr55+nbfNA6whhKBw+mTtwWrHX4RPmniMzbSEUE3dtg6mzk0OJnm LeuZW8Fiju+evy8mA65rLpUIqJAoKALP0UctpvzbEYvVJ4sQ2Nf/SQ1KLxAvAClgbPwV Y7XvvB+pdkjLhB1CTDa6+F+T2YgVwgEEMP7OXRNdfDHJL0B+LUoZMZCdNixFOjXRsxEt /2SvHgWqmV/3aQmacEi5O5Js4Qf1236Oisez4bsj7UdCz+9Lz7IFplBrxaf8djdby5QI 43Ng== X-Gm-Message-State: ALoCoQknWOSC/citiwZhdRI6uJWT2zO60cFBL6NfDS/pdRDBIXPBg+5F/KPpUMso3D/AuXz5ge+v MIME-Version: 1.0 X-Received: by 10.194.110.67 with SMTP id hy3mr8212364wjb.87.1431609582917; Thu, 14 May 2015 06:19:42 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 06:19:42 -0700 (PDT) In-Reply-To: References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> Date: Thu, 14 May 2015 15:19:42 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7600058166511092792==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============7600058166511092792== Content-Type: multipart/alternative; boundary=089e010d8292a5ae9505160a9478 --089e010d8292a5ae9505160a9478 Content-Type: text/plain; charset=UTF-8 > > I think it is worth pointing pout that people use PVHVM (HVM) for >> performance reasons also. One gets the impression from this paragraph that >> the only reason >> > > Ack. > > Actually, I think this segways a lot from the origin discussion and people may not necessarily know the difference between PVHVM/PVH/PV/HVM to follow.. -- [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --089e010d8292a5ae9505160a9478 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
=
I think it is worth pointing pout that people use PVHVM (HVM) for performan= ce reasons also. One gets the impression from this paragraph that the only = reason

Ack.


Actu= ally, I think this segways a lot from the origin discussion and people may = not necessarily know the difference between PVHVM/PVH/PV/HVM to follow..

--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--089e010d8292a5ae9505160a9478-- --===============7600058166511092792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============7600058166511092792==-- From publicity-bounces@lists.xenproject.org Thu May 14 13:31:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 13:31:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstE6-0000NP-8X; Thu, 14 May 2015 13:31:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstE4-0000N2-R7 for publicity@lists.xenproject.org; Thu, 14 May 2015 13:31:00 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 7B/73-02819-393A4555; Thu, 14 May 2015 13:30:59 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1431610259!9547046!1 X-Originating-IP: [74.125.82.42] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6818 invoked from network); 14 May 2015 13:30:59 -0000 Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com) (74.125.82.42) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 13:30:59 -0000 Received: by wgbhc8 with SMTP id hc8so42031736wgb.3 for ; Thu, 14 May 2015 06:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rJt11yg1S3j8+1QYRjeA8/rQN60fRet0Spb5i5/Okeg=; b=CWBlzZPs9FvUGZy/5A5th3UGtCi9pVcjrdLIOYiy9KF8Rd3YA2OWMKAQ0lziqoAHNh EHEiL0GQBbHUh53UcpkmxIlQTNiiooUNJ9rBFNXBIcfxLE8HYHuEgyCAqdHu8bLZbmEb juVCoFewSOfDmx3lEM64d98S9sl4O1ITn2hhCaSu+Yk2i4meuRnmaGeJcHgVGGXxICeG /BLlm5i/ysHFvu4t4CIoJQyCGCT+ZDVrNEQSwk2sNHVQfTXYE4L1ktRfj2aTOyuunOzB E+miVxzxM4Oqd7C9ZYM4r/au5GxWRO/v1S7p+uVBOVhV31tKuPLCyW75indpWkdx8ZOW wkEA== X-Received: by 10.194.52.37 with SMTP id q5mr8428446wjo.122.1431610258837; Thu, 14 May 2015 06:30:58 -0700 (PDT) Received: from [10.80.114.117] ([185.25.64.249]) by mx.google.com with ESMTPSA id ju2sm13330930wid.12.2015.05.14.06.30.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 06:30:57 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 14:30:54 +0100 Message-Id: <693BB871-6B82-4E66-8360-A1CDF10CFAFA@gmail.com> References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660942418415079534==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============0660942418415079534== Content-Type: multipart/alternative; boundary="Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2" --Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14 May 2015, at 14:19, Lengyel, Tamas wrote: >=20 >=20 >=20 > I think it is worth pointing pout that people use PVHVM (HVM) for = performance reasons also. One gets the impression from this paragraph = that the only reason >=20 > Ack. >=20 >=20 > Actually, I think this segways a lot from the origin discussion and = people may not necessarily know the difference between PVHVM/PVH/PV/HVM = to follow.. Fine with me Lars= --Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 14 May 2015, at 14:19, Lengyel, Tamas <tlengyel@novetta.com> wrote:



I think it is worth pointing pout that people use PVHVM (HVM) for performance reasons also. One gets the impression from this paragraph that the only reason

Ack.


Actually, I think this segways a lot from the origin discussion and people may not necessarily know the difference between PVHVM/PVH/PV/HVM to follow..

Fine with me
Lars
--Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2-- --===============0660942418415079534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============0660942418415079534==-- From publicity-bounces@lists.xenproject.org Thu May 14 13:31:03 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 13:31:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstE6-0000NP-8X; Thu, 14 May 2015 13:31:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstE4-0000N2-R7 for publicity@lists.xenproject.org; Thu, 14 May 2015 13:31:00 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 7B/73-02819-393A4555; Thu, 14 May 2015 13:30:59 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1431610259!9547046!1 X-Originating-IP: [74.125.82.42] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6818 invoked from network); 14 May 2015 13:30:59 -0000 Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com) (74.125.82.42) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 13:30:59 -0000 Received: by wgbhc8 with SMTP id hc8so42031736wgb.3 for ; Thu, 14 May 2015 06:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rJt11yg1S3j8+1QYRjeA8/rQN60fRet0Spb5i5/Okeg=; b=CWBlzZPs9FvUGZy/5A5th3UGtCi9pVcjrdLIOYiy9KF8Rd3YA2OWMKAQ0lziqoAHNh EHEiL0GQBbHUh53UcpkmxIlQTNiiooUNJ9rBFNXBIcfxLE8HYHuEgyCAqdHu8bLZbmEb juVCoFewSOfDmx3lEM64d98S9sl4O1ITn2hhCaSu+Yk2i4meuRnmaGeJcHgVGGXxICeG /BLlm5i/ysHFvu4t4CIoJQyCGCT+ZDVrNEQSwk2sNHVQfTXYE4L1ktRfj2aTOyuunOzB E+miVxzxM4Oqd7C9ZYM4r/au5GxWRO/v1S7p+uVBOVhV31tKuPLCyW75indpWkdx8ZOW wkEA== X-Received: by 10.194.52.37 with SMTP id q5mr8428446wjo.122.1431610258837; Thu, 14 May 2015 06:30:58 -0700 (PDT) Received: from [10.80.114.117] ([185.25.64.249]) by mx.google.com with ESMTPSA id ju2sm13330930wid.12.2015.05.14.06.30.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 06:30:57 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 14:30:54 +0100 Message-Id: <693BB871-6B82-4E66-8360-A1CDF10CFAFA@gmail.com> References: <55547EFA.8060504@eu.citrix.com> <0A27BE24-A271-4F0A-84D0-4AA77BC3EE37@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660942418415079534==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============0660942418415079534== Content-Type: multipart/alternative; boundary="Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2" --Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14 May 2015, at 14:19, Lengyel, Tamas wrote: >=20 >=20 >=20 > I think it is worth pointing pout that people use PVHVM (HVM) for = performance reasons also. One gets the impression from this paragraph = that the only reason >=20 > Ack. >=20 >=20 > Actually, I think this segways a lot from the origin discussion and = people may not necessarily know the difference between PVHVM/PVH/PV/HVM = to follow.. Fine with me Lars= --Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 14 May 2015, at 14:19, Lengyel, Tamas <tlengyel@novetta.com> wrote:



I think it is worth pointing pout that people use PVHVM (HVM) for performance reasons also. One gets the impression from this paragraph that the only reason

Ack.


Actually, I think this segways a lot from the origin discussion and people may not necessarily know the difference between PVHVM/PVH/PV/HVM to follow..

Fine with me
Lars
--Apple-Mail=_42F20592-916D-47B7-BD3C-A13FF801DED2-- --===============0660942418415079534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============0660942418415079534==-- From publicity-bounces@lists.xenproject.org Thu May 14 13:32:49 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 13:32:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstFp-0000XN-77; Thu, 14 May 2015 13:32:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstFn-0000Wr-Lc for publicity@lists.xenproject.org; Thu, 14 May 2015 13:32:47 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 3E/52-02788-EF3A4555; Thu, 14 May 2015 13:32:46 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1431610364!11464830!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14528 invoked from network); 14 May 2015 13:32:44 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 13:32:44 -0000 Received: by wicmx19 with SMTP id mx19so16855459wic.0 for ; Thu, 14 May 2015 06:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=f2eKnzimBMgq2KCt0Wtv6JdYlhq53Al3a3i2OzVFa6M=; b=Ot4eKM5eI66gtMT15O4hKfAqCLW8LjUZhEwKZRDw/w0T0bD790N63Ac5kJnYN/BgSa MlIaJyRNT6JaiaRAHdcEQv6SYuJ4tTMCOcN0RWEh/wi0FGVtOuPSahdoMQmwT6IQchWW XGttlAHXqBW4aEDM4QFY89sg4qsHNDKOjidu9jxWbtkNjTliEGaawJdpAnNwS5FbAFFf k73qJJbqo9EAFhFouwzMYIna8dR7NXQbYM1PbaDllo6tvY+ZWF1LK5P69JW3sJ5vlW0v FJZwzCjpMmJDbP0xZKFEqi6j9DMJtFCfu8aqunBvjSMhjBa+gRFspSLR/z+uqEdJ+76Y hPDQ== X-Gm-Message-State: ALoCoQnyuZUePbVRh4JJ2OSdfq2OAOxm6Qh2JcqXMyTgU0l2aPziNVmtAiDSzp6wVgnATHxrmYdQ MIME-Version: 1.0 X-Received: by 10.194.57.40 with SMTP id f8mr8481411wjq.86.1431610363827; Thu, 14 May 2015 06:32:43 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 06:32:43 -0700 (PDT) Date: Thu, 14 May 2015 15:32:43 +0200 Message-ID: From: "Lengyel, Tamas" To: publicity@lists.xenproject.org Subject: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5875749795521325310==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============5875749795521325310== Content-Type: multipart/alternative; boundary=047d7ba97b9c3171f605160ac32a --047d7ba97b9c3171f605160ac32a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open sou= rce enthusiast and Xen contributor. Tamas works as Senior Security Researcher at Novetta, while finishing his PhD on the topic of malware analysis and virtualization security at the University of Connecticut. ------------- Hardening Xen against VENOM-style attacks The recent disclosure of the VENOM[1] bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating in the tech news as of 5/13/15, causing many to reevaluate their risks when using cloud infrastructures. That is a very good thing indeed. Virtualization and the cloud have been erroneously considered by many to be a silver bullet against intrusions and malware in general. The fact is that the cloud is anything but a safe place. There are inherent risks in the cloud, thus it is very important to put those risks in context. Hypervisors, same as any other complex software systems, are prone to bugs and errors. VENOM in that sense is just another one in the long list of vulnerabilities that have been popping up against hypervisors[2]. While VENOM is indeed a serious bug and can result in a VM escape, which in turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known for a long time. And there are easy-to-deploy counter-measures to mitigate the risk of such exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog post on t= he same topic[3]). What is the root cause of VENOM? Emulation. While modern systems come with a plethora of virtualization extensions, many components are still being emulated. The biggest component of that are usually devices. Devices such as your network card, graphics card and your hard drive. While Linux comes with paravirtual (virtualization-aware) drivers to create such devices, emulation is often the only solution to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows[4]. This emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent years. However, QEMU is not the only place where emulation is used within Xen. For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for performance and scalability reasons[5]. As with QEMU, this emulator has been just as exploitable[6]. This is simply because to program emulating devices and services properly is really complex and error-prone. This fact, that emulation is complex and error-prone, has been known for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM escape attack against KVM, through QEMU. The author of Virtunoid even cautioned there will be many other bugs of that nature found by researchers. Fast-forward 4 years and we now have VENOM. The good news is there is an easy mitigation available for all present and future QEMU bugs, also mentioned in the original Xen Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU into a deprivileged domain of its own. Instead of having QEMU run as root in dom0, a stubdomain has access only to the VM it is providing emulation for. Thus, an escape through QEMU will only land an attacker in a stubdomain, without access to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an attacker would only have a very limited environment to run code in (as in return-to-libc/ROP-style), having exactly the same level of privilege as in the domain where the attack started. Nothing is to be gained for a lot of work, effectively making the system as secure as it would be if only PV drivers were used. One would think it is a complex process to take advantage of this protection, but in fact, it is very simple. Add the following line to your Xen domain configuration and you gain immediate protection against VENOM, and the whole class of vulnerabilities brought to you by QEMU: device_model_stubdomain_override =3D 1 However, as with most security systems, it comes at a cost. Running stubdomains requires a bit of extra memory as compared to the plain QEMU process in dom0. This in turn can limit the number of VMs a cloud provider may be able to sell, thus there is limited incentive on their end to enable this feature by default. Further complicating the picture is the fact that this protection works best if all VMs on the server run with stubdomains. Otherwise you may end up protecting your neighbors against an escape attack from your domain, while not being protected from an escape attack from theirs. It is thus no surprise if some users would not want to pay for this extra protection, even if it was available. However, for private clouds and exclusive servers there is no reason why it shouldn=E2=80=99t be your defau= lt setting. ________________ [1] http://venom.crowdstrike.com/ [2] http://xenbits.xen.org/xsa/ [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. [4] Citrix recently open-sourced its Windows PV drivers so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 [6] http://xenbits.xen.org/xsa/advisory-105.html [7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf [8] http://xenbits.xen.org/xsa/advisory-133.html [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --047d7ba97b9c3171f605160ac32a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a l= ong-time open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of mal= ware analysis and virtualization security at the University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://venom.crowdstrike.= com/
[2] http://xenbits.xen.org/xsa/=
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten= /.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv-drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xen= bits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elha= ge_Virtunoid_WP.pdf
[8] http://xen= bits.xen.org/xsa/advisory-133.html
[9] http= ://wiki.xen.org/wiki/Device_Model_Stub_Domains

-- =

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--047d7ba97b9c3171f605160ac32a-- --===============5875749795521325310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============5875749795521325310==-- From publicity-bounces@lists.xenproject.org Thu May 14 13:32:49 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 13:32:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstFp-0000XN-77; Thu, 14 May 2015 13:32:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YstFn-0000Wr-Lc for publicity@lists.xenproject.org; Thu, 14 May 2015 13:32:47 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 3E/52-02788-EF3A4555; Thu, 14 May 2015 13:32:46 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1431610364!11464830!1 X-Originating-IP: [209.85.212.176] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14528 invoked from network); 14 May 2015 13:32:44 -0000 Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 13:32:44 -0000 Received: by wicmx19 with SMTP id mx19so16855459wic.0 for ; Thu, 14 May 2015 06:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=f2eKnzimBMgq2KCt0Wtv6JdYlhq53Al3a3i2OzVFa6M=; b=Ot4eKM5eI66gtMT15O4hKfAqCLW8LjUZhEwKZRDw/w0T0bD790N63Ac5kJnYN/BgSa MlIaJyRNT6JaiaRAHdcEQv6SYuJ4tTMCOcN0RWEh/wi0FGVtOuPSahdoMQmwT6IQchWW XGttlAHXqBW4aEDM4QFY89sg4qsHNDKOjidu9jxWbtkNjTliEGaawJdpAnNwS5FbAFFf k73qJJbqo9EAFhFouwzMYIna8dR7NXQbYM1PbaDllo6tvY+ZWF1LK5P69JW3sJ5vlW0v FJZwzCjpMmJDbP0xZKFEqi6j9DMJtFCfu8aqunBvjSMhjBa+gRFspSLR/z+uqEdJ+76Y hPDQ== X-Gm-Message-State: ALoCoQnyuZUePbVRh4JJ2OSdfq2OAOxm6Qh2JcqXMyTgU0l2aPziNVmtAiDSzp6wVgnATHxrmYdQ MIME-Version: 1.0 X-Received: by 10.194.57.40 with SMTP id f8mr8481411wjq.86.1431610363827; Thu, 14 May 2015 06:32:43 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 06:32:43 -0700 (PDT) Date: Thu, 14 May 2015 15:32:43 +0200 Message-ID: From: "Lengyel, Tamas" To: publicity@lists.xenproject.org Subject: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5875749795521325310==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============5875749795521325310== Content-Type: multipart/alternative; boundary=047d7ba97b9c3171f605160ac32a --047d7ba97b9c3171f605160ac32a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open sou= rce enthusiast and Xen contributor. Tamas works as Senior Security Researcher at Novetta, while finishing his PhD on the topic of malware analysis and virtualization security at the University of Connecticut. ------------- Hardening Xen against VENOM-style attacks The recent disclosure of the VENOM[1] bug affecting major open-source hypervisors, such as KVM and Xen, has been circulating in the tech news as of 5/13/15, causing many to reevaluate their risks when using cloud infrastructures. That is a very good thing indeed. Virtualization and the cloud have been erroneously considered by many to be a silver bullet against intrusions and malware in general. The fact is that the cloud is anything but a safe place. There are inherent risks in the cloud, thus it is very important to put those risks in context. Hypervisors, same as any other complex software systems, are prone to bugs and errors. VENOM in that sense is just another one in the long list of vulnerabilities that have been popping up against hypervisors[2]. While VENOM is indeed a serious bug and can result in a VM escape, which in turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known for a long time. And there are easy-to-deploy counter-measures to mitigate the risk of such exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog post on t= he same topic[3]). What is the root cause of VENOM? Emulation. While modern systems come with a plethora of virtualization extensions, many components are still being emulated. The biggest component of that are usually devices. Devices such as your network card, graphics card and your hard drive. While Linux comes with paravirtual (virtualization-aware) drivers to create such devices, emulation is often the only solution to run operating systems that do not have such kernel drivers. This has been traditionally the case with Windows[4]. This emulation layer has been implemented in QEMU, which has caused VENOM and a handful of other VM-escape bugs in recent years. However, QEMU is not the only place where emulation is used within Xen. For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for performance and scalability reasons[5]. As with QEMU, this emulator has been just as exploitable[6]. This is simply because to program emulating devices and services properly is really complex and error-prone. This fact, that emulation is complex and error-prone, has been known for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM escape attack against KVM, through QEMU. The author of Virtunoid even cautioned there will be many other bugs of that nature found by researchers. Fast-forward 4 years and we now have VENOM. The good news is there is an easy mitigation available for all present and future QEMU bugs, also mentioned in the original Xen Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU into a deprivileged domain of its own. Instead of having QEMU run as root in dom0, a stubdomain has access only to the VM it is providing emulation for. Thus, an escape through QEMU will only land an attacker in a stubdomain, without access to critical resources. Furthermore, QEMU in a stubdomain runs on MiniOS, thus an attacker would only have a very limited environment to run code in (as in return-to-libc/ROP-style), having exactly the same level of privilege as in the domain where the attack started. Nothing is to be gained for a lot of work, effectively making the system as secure as it would be if only PV drivers were used. One would think it is a complex process to take advantage of this protection, but in fact, it is very simple. Add the following line to your Xen domain configuration and you gain immediate protection against VENOM, and the whole class of vulnerabilities brought to you by QEMU: device_model_stubdomain_override =3D 1 However, as with most security systems, it comes at a cost. Running stubdomains requires a bit of extra memory as compared to the plain QEMU process in dom0. This in turn can limit the number of VMs a cloud provider may be able to sell, thus there is limited incentive on their end to enable this feature by default. Further complicating the picture is the fact that this protection works best if all VMs on the server run with stubdomains. Otherwise you may end up protecting your neighbors against an escape attack from your domain, while not being protected from an escape attack from theirs. It is thus no surprise if some users would not want to pay for this extra protection, even if it was available. However, for private clouds and exclusive servers there is no reason why it shouldn=E2=80=99t be your defau= lt setting. ________________ [1] http://venom.crowdstrike.com/ [2] http://xenbits.xen.org/xsa/ [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. [4] Citrix recently open-sourced its Windows PV drivers so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 [6] http://xenbits.xen.org/xsa/advisory-105.html [7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf [8] http://xenbits.xen.org/xsa/advisory-133.html [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --047d7ba97b9c3171f605160ac32a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a l= ong-time open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of mal= ware analysis and virtualization security at the University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://venom.crowdstrike.= com/
[2] http://xenbits.xen.org/xsa/=
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten= /.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv-drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xen= bits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elha= ge_Virtunoid_WP.pdf
[8] http://xen= bits.xen.org/xsa/advisory-133.html
[9] http= ://wiki.xen.org/wiki/Device_Model_Stub_Domains

-- =

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--047d7ba97b9c3171f605160ac32a-- --===============5875749795521325310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============5875749795521325310==-- From publicity-bounces@lists.xenproject.org Thu May 14 15:20:13 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 15:20:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysuvl-0002IX-AE; Thu, 14 May 2015 15:20:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysuvj-0002IL-Sv for publicity@lists.xenproject.org; Thu, 14 May 2015 15:20:12 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id CD/88-03286-A2DB4555; Thu, 14 May 2015 15:20:10 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1431616807!11010639!1 X-Originating-IP: [209.85.212.180] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22554 invoked from network); 14 May 2015 15:20:08 -0000 Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com) (209.85.212.180) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 15:20:08 -0000 Received: by wizk4 with SMTP id k4so245648197wiz.1 for ; Thu, 14 May 2015 08:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UyvtMzThdhGtDydRnLUpzfXlYTASc2v6d3gfwIWtlKQ=; b=vpmd4dTezGIJnjI05+L/ZjS/nD+RxoCyqCRuBMvuOHoYx2smc1hFM/WHfL/OQoOE8r d9tHDoOgw85Gn1d759z98IShxyrSdYz9bbnJY5xMRkIe8b7wVU8ul0jd2Tp9DLpVAS5p dZI/gORby2ycXvez7gDBoN0iPUhg+WWkZe2OqqoHIjoP+xarxLMJRkco2EfyZsi8LAlh 54SOqQpJjKJ4ZUl3WzjDhDaM2tOE2RUbCGcl3vpBNR9XClG7DPAU7z28JbSprs4UXbhy yN5OeI3kTcmXoF0hSHB1QCP7lHRK9xJ27UWlKmtygOCsN6ZGs56A4T/XolOiw/rBiYQH qamQ== X-Received: by 10.180.231.4 with SMTP id tc4mr25317041wic.27.1431616807611; Thu, 14 May 2015 08:20:07 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id b10sm10219427wic.1.2015.05.14.08.20.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 08:20:06 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 16:20:04 +0100 Message-Id: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> References: To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4807009006671046291==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============4807009006671046291== Content-Type: multipart/alternative; boundary="Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849" --Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks fine to me Unless there are further comments, I will encode this in the blog in an = hour or so @Tamas: I will create an account for you and publish under your name. = You will then have to reset your password Cheers Lars =20 > On 14 May 2015, at 14:32, Lengyel, Tamas wrote: >=20 > =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time = open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of = malware analysis and virtualization security at the University of = Connecticut.=20 > =20 > ------------- > Hardening Xen against VENOM-style attacks=20 > =20 > =20 > The recent disclosure of the VENOM[1] bug affecting major open-source = hypervisors, such as KVM and Xen, has been circulating in the tech news = as of 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.=20 > =20 > =20 > Hypervisors, same as any other complex software systems, are prone to = bugs and errors. VENOM in that sense is just another one in the long = list of vulnerabilities that have been popping up against = hypervisors[2]. While VENOM is indeed a serious bug and can result in a = VM escape, which in turn can compromise all VMs on the host, it = doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known = for a long time. And there are easy-to-deploy counter-measures to = mitigate the risk of such exploits, natively available in both Xen and = KVM (see RedHat=E2=80=99s blog post on the same topic[3]).=20 > =20 > =20 > What is the root cause of VENOM? Emulation.=20 > =20 > =20 > While modern systems come with a plethora of virtualization = extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network = card, graphics card and your hard drive. While Linux comes with = paravirtual (virtualization-aware) drivers to create such devices, = emulation is often the only solution to run operating systems that do = not have such kernel drivers. This has been traditionally the case with = Windows[4]. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. = However, QEMU is not the only place where emulation is used within Xen. = For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, = PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. =20 > =20 > =20 > This fact, that emulation is complex and error-prone, has been known = for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] = demonstrated such a VM escape attack against KVM, through QEMU. The = author of Virtunoid even cautioned there will be many other bugs of that = nature found by researchers. Fast-forward 4 years and we now have VENOM.=20= > =20 > =20 > The good news is there is an easy mitigation available for all present = and future QEMU bugs, also mentioned in the original Xen Security = Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole = class of vulnerabilities exposed by QEMU in the bud by moving QEMU into = a deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.=20= > =20 > =20 > One would think it is a complex process to take advantage of this = protection, but in fact, it is very simple. Add the following line to = your Xen domain configuration and you gain immediate protection against = VENOM, and the whole class of vulnerabilities brought to you by QEMU:=20 >=20 > device_model_stubdomain_override =3D 1 =20 > =20 > However, as with most security systems, it comes at a cost. Running = stubdomains requires a bit of extra memory as compared to the plain QEMU = process in dom0. This in turn can limit the number of VMs a cloud = provider may be able to sell, thus there is limited incentive on their = end to enable this feature by default. Further complicating the picture = is the fact that this protection works best if all VMs on the server run = with stubdomains. Otherwise you may end up protecting your neighbors = against an escape attack from your domain, while not being protected = from an escape attack from theirs. It is thus no surprise if some users = would not want to pay for this extra protection, even if it was = available. However, for private clouds and exclusive servers there is no = reason why it shouldn=E2=80=99t be your default setting. =20 > ________________=20 > [1] http://venom.crowdstrike.com/ =20 > [2] http://xenbits.xen.org/xsa/ =20 > [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/ = .=20 > [4] Citrix recently open-sourced its Windows PV drivers so it is no = longer the case: = http://www.xenproject.org/downloads/windows-pv-drivers.html = =20 > [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 = =20 > [6] http://xenbits.xen.org/xsa/advisory-105.html = =20 > [7] = http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf= = =20 > [8] http://xenbits.xen.org/xsa/advisory-133.html = =20 > [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains = >=20 > --=20 > =20 > Tamas K Lengyel > Senior Security Researcher >=20 > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com = _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looks fine to me
Unless there are further = comments, I will encode this in the blog in an hour or so

@Tamas: I will create an = account for you and publish under your name. You will then have to reset = your password

Cheers
Lars
 

On 14 May 2015, at 14:32, = Lengyel, Tamas <tlengyel@novetta.com> wrote:

=EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a = long-time open source enthusiast and Xen contributor. Tamas works as = Senior Security Researcher at Novetta, while finishing his PhD on the = topic of malware analysis and virtualization security at the University = of Connecticut.
 
-------------
Hardening = Xen against VENOM-style attacks
 
 
The recent = disclosure of the VENOM[1] bug affecting major open-source hypervisors, = such as KVM and Xen, has been circulating in the tech news as of = 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.
 
 
Hypervisors, = same as any other complex software systems, are prone to bugs and = errors. VENOM in that sense is just another one in the long list of = vulnerabilities that have been popping up against hypervisors[2]. While = VENOM is indeed a serious bug and can result in a VM escape, which in = turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. = In fact, VENOM-style attacks have been known for a long time. And there = are easy-to-deploy counter-measures to mitigate the risk of such = exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s = blog post on the same topic[3]).
 
 
What is the = root cause of VENOM? Emulation.
 
 
While modern = systems come with a plethora of virtualization extensions, many = components are still being emulated. The biggest component of that are = usually devices. Devices such as your network card, graphics card and = your hard drive. While Linux comes with paravirtual = (virtualization-aware) drivers to create such devices, emulation is = often the only solution to run operating systems that do not have such = kernel drivers. This has been traditionally the case with Windows[4]. = This emulation layer has been implemented in QEMU, which has caused = VENOM and a handful of other VM-escape bugs in recent years. However, = QEMU is not the only place where emulation is used within Xen. For a = variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, = IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. 
 
 
This fact, that = emulation is complex and error-prone, has been known for a long time. = Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM = escape attack against KVM, through QEMU. The author of Virtunoid even = cautioned there will be many other bugs of that nature found by = researchers. Fast-forward 4 years and we now have VENOM.
 
 
The good news = is there is an easy mitigation available for all present and future QEMU = bugs, also mentioned in the original Xen Security Advisory[8]. It is = called stubdomains[9]. Stubdomains can nip the whole class of = vulnerabilities exposed by QEMU in the bud by moving QEMU into a = deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.
 
 
One would think = it is a complex process to take advantage of this protection, but in = fact, it is very simple. Add the following line to your Xen domain = configuration and you gain immediate protection against VENOM, and the = whole class of vulnerabilities brought to you by QEMU:

device_model_stubdomain_override =3D = 1 
 
However, as with most security = systems, it comes at a cost. Running stubdomains requires a bit of extra = memory as compared to the plain QEMU process in dom0. This in turn can = limit the number of VMs a cloud provider may be able to sell, thus there = is limited incentive on their end to enable this feature by default. = Further complicating the picture is the fact that this protection works = best if all VMs on the server run with stubdomains. Otherwise you may = end up protecting your neighbors against an escape attack from your = domain, while not being protected from an escape attack from theirs. It = is thus no surprise if some users would not want to pay for this extra = protection, even if it was available. However, for private clouds and = exclusive servers there is no reason why it shouldn=E2=80=99t be your = default setting. 
________________
[1] http://venom.crowdstrike.com/
[2] http://xenbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitte= n/.
[4] Citrix recently open-sourced its Windows PV drivers = so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html=
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtu= noid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= br class=3D"">

= --Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849-- --===============4807009006671046291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============4807009006671046291==-- From publicity-bounces@lists.xenproject.org Thu May 14 15:20:13 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 15:20:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysuvl-0002IX-AE; Thu, 14 May 2015 15:20:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Ysuvj-0002IL-Sv for publicity@lists.xenproject.org; Thu, 14 May 2015 15:20:12 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id CD/88-03286-A2DB4555; Thu, 14 May 2015 15:20:10 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1431616807!11010639!1 X-Originating-IP: [209.85.212.180] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22554 invoked from network); 14 May 2015 15:20:08 -0000 Received: from mail-wi0-f180.google.com (HELO mail-wi0-f180.google.com) (209.85.212.180) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 15:20:08 -0000 Received: by wizk4 with SMTP id k4so245648197wiz.1 for ; Thu, 14 May 2015 08:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UyvtMzThdhGtDydRnLUpzfXlYTASc2v6d3gfwIWtlKQ=; b=vpmd4dTezGIJnjI05+L/ZjS/nD+RxoCyqCRuBMvuOHoYx2smc1hFM/WHfL/OQoOE8r d9tHDoOgw85Gn1d759z98IShxyrSdYz9bbnJY5xMRkIe8b7wVU8ul0jd2Tp9DLpVAS5p dZI/gORby2ycXvez7gDBoN0iPUhg+WWkZe2OqqoHIjoP+xarxLMJRkco2EfyZsi8LAlh 54SOqQpJjKJ4ZUl3WzjDhDaM2tOE2RUbCGcl3vpBNR9XClG7DPAU7z28JbSprs4UXbhy yN5OeI3kTcmXoF0hSHB1QCP7lHRK9xJ27UWlKmtygOCsN6ZGs56A4T/XolOiw/rBiYQH qamQ== X-Received: by 10.180.231.4 with SMTP id tc4mr25317041wic.27.1431616807611; Thu, 14 May 2015 08:20:07 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id b10sm10219427wic.1.2015.05.14.08.20.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 08:20:06 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 16:20:04 +0100 Message-Id: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> References: To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4807009006671046291==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============4807009006671046291== Content-Type: multipart/alternative; boundary="Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849" --Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks fine to me Unless there are further comments, I will encode this in the blog in an = hour or so @Tamas: I will create an account for you and publish under your name. = You will then have to reset your password Cheers Lars =20 > On 14 May 2015, at 14:32, Lengyel, Tamas wrote: >=20 > =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time = open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of = malware analysis and virtualization security at the University of = Connecticut.=20 > =20 > ------------- > Hardening Xen against VENOM-style attacks=20 > =20 > =20 > The recent disclosure of the VENOM[1] bug affecting major open-source = hypervisors, such as KVM and Xen, has been circulating in the tech news = as of 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.=20 > =20 > =20 > Hypervisors, same as any other complex software systems, are prone to = bugs and errors. VENOM in that sense is just another one in the long = list of vulnerabilities that have been popping up against = hypervisors[2]. While VENOM is indeed a serious bug and can result in a = VM escape, which in turn can compromise all VMs on the host, it = doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known = for a long time. And there are easy-to-deploy counter-measures to = mitigate the risk of such exploits, natively available in both Xen and = KVM (see RedHat=E2=80=99s blog post on the same topic[3]).=20 > =20 > =20 > What is the root cause of VENOM? Emulation.=20 > =20 > =20 > While modern systems come with a plethora of virtualization = extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network = card, graphics card and your hard drive. While Linux comes with = paravirtual (virtualization-aware) drivers to create such devices, = emulation is often the only solution to run operating systems that do = not have such kernel drivers. This has been traditionally the case with = Windows[4]. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. = However, QEMU is not the only place where emulation is used within Xen. = For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, = PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. =20 > =20 > =20 > This fact, that emulation is complex and error-prone, has been known = for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] = demonstrated such a VM escape attack against KVM, through QEMU. The = author of Virtunoid even cautioned there will be many other bugs of that = nature found by researchers. Fast-forward 4 years and we now have VENOM.=20= > =20 > =20 > The good news is there is an easy mitigation available for all present = and future QEMU bugs, also mentioned in the original Xen Security = Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole = class of vulnerabilities exposed by QEMU in the bud by moving QEMU into = a deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.=20= > =20 > =20 > One would think it is a complex process to take advantage of this = protection, but in fact, it is very simple. Add the following line to = your Xen domain configuration and you gain immediate protection against = VENOM, and the whole class of vulnerabilities brought to you by QEMU:=20 >=20 > device_model_stubdomain_override =3D 1 =20 > =20 > However, as with most security systems, it comes at a cost. Running = stubdomains requires a bit of extra memory as compared to the plain QEMU = process in dom0. This in turn can limit the number of VMs a cloud = provider may be able to sell, thus there is limited incentive on their = end to enable this feature by default. Further complicating the picture = is the fact that this protection works best if all VMs on the server run = with stubdomains. Otherwise you may end up protecting your neighbors = against an escape attack from your domain, while not being protected = from an escape attack from theirs. It is thus no surprise if some users = would not want to pay for this extra protection, even if it was = available. However, for private clouds and exclusive servers there is no = reason why it shouldn=E2=80=99t be your default setting. =20 > ________________=20 > [1] http://venom.crowdstrike.com/ =20 > [2] http://xenbits.xen.org/xsa/ =20 > [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/ = .=20 > [4] Citrix recently open-sourced its Windows PV drivers so it is no = longer the case: = http://www.xenproject.org/downloads/windows-pv-drivers.html = =20 > [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 = =20 > [6] http://xenbits.xen.org/xsa/advisory-105.html = =20 > [7] = http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf= = =20 > [8] http://xenbits.xen.org/xsa/advisory-133.html = =20 > [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains = >=20 > --=20 > =20 > Tamas K Lengyel > Senior Security Researcher >=20 > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com = _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looks fine to me
Unless there are further = comments, I will encode this in the blog in an hour or so

@Tamas: I will create an = account for you and publish under your name. You will then have to reset = your password

Cheers
Lars
 

On 14 May 2015, at 14:32, = Lengyel, Tamas <tlengyel@novetta.com> wrote:

=EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a = long-time open source enthusiast and Xen contributor. Tamas works as = Senior Security Researcher at Novetta, while finishing his PhD on the = topic of malware analysis and virtualization security at the University = of Connecticut.
 
-------------
Hardening = Xen against VENOM-style attacks
 
 
The recent = disclosure of the VENOM[1] bug affecting major open-source hypervisors, = such as KVM and Xen, has been circulating in the tech news as of = 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.
 
 
Hypervisors, = same as any other complex software systems, are prone to bugs and = errors. VENOM in that sense is just another one in the long list of = vulnerabilities that have been popping up against hypervisors[2]. While = VENOM is indeed a serious bug and can result in a VM escape, which in = turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. = In fact, VENOM-style attacks have been known for a long time. And there = are easy-to-deploy counter-measures to mitigate the risk of such = exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s = blog post on the same topic[3]).
 
 
What is the = root cause of VENOM? Emulation.
 
 
While modern = systems come with a plethora of virtualization extensions, many = components are still being emulated. The biggest component of that are = usually devices. Devices such as your network card, graphics card and = your hard drive. While Linux comes with paravirtual = (virtualization-aware) drivers to create such devices, emulation is = often the only solution to run operating systems that do not have such = kernel drivers. This has been traditionally the case with Windows[4]. = This emulation layer has been implemented in QEMU, which has caused = VENOM and a handful of other VM-escape bugs in recent years. However, = QEMU is not the only place where emulation is used within Xen. For a = variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, = IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. 
 
 
This fact, that = emulation is complex and error-prone, has been known for a long time. = Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM = escape attack against KVM, through QEMU. The author of Virtunoid even = cautioned there will be many other bugs of that nature found by = researchers. Fast-forward 4 years and we now have VENOM.
 
 
The good news = is there is an easy mitigation available for all present and future QEMU = bugs, also mentioned in the original Xen Security Advisory[8]. It is = called stubdomains[9]. Stubdomains can nip the whole class of = vulnerabilities exposed by QEMU in the bud by moving QEMU into a = deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.
 
 
One would think = it is a complex process to take advantage of this protection, but in = fact, it is very simple. Add the following line to your Xen domain = configuration and you gain immediate protection against VENOM, and the = whole class of vulnerabilities brought to you by QEMU:

device_model_stubdomain_override =3D = 1 
 
However, as with most security = systems, it comes at a cost. Running stubdomains requires a bit of extra = memory as compared to the plain QEMU process in dom0. This in turn can = limit the number of VMs a cloud provider may be able to sell, thus there = is limited incentive on their end to enable this feature by default. = Further complicating the picture is the fact that this protection works = best if all VMs on the server run with stubdomains. Otherwise you may = end up protecting your neighbors against an escape attack from your = domain, while not being protected from an escape attack from theirs. It = is thus no surprise if some users would not want to pay for this extra = protection, even if it was available. However, for private clouds and = exclusive servers there is no reason why it shouldn=E2=80=99t be your = default setting. 
________________
[1] http://venom.crowdstrike.com/
[2] http://xenbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitte= n/.
[4] Citrix recently open-sourced its Windows PV drivers = so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html=
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtu= noid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= br class=3D"">

= --Apple-Mail=_640ED43E-D302-4F0F-A8CD-A6C2681F6849-- --===============4807009006671046291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============4807009006671046291==-- From publicity-bounces@lists.xenproject.org Thu May 14 16:07:27 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 16:07:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsvfS-0005mS-0g; Thu, 14 May 2015 16:07:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsvfR-0005mN-9y for publicity@lists.xenproject.org; Thu, 14 May 2015 16:07:25 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 5A/BE-02776-C38C4555; Thu, 14 May 2015 16:07:24 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1431619641!15457083!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13887 invoked from network); 14 May 2015 16:07:21 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 16:07:21 -0000 Received: by wgnd10 with SMTP id d10so78223567wgn.2 for ; Thu, 14 May 2015 09:07:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/oEC/9jhbhW4ORw8LkK2aM9nob7PSwNkHNamOs07qY8=; b=Bu8NKWf3CJH5s5eN5CYG8dHjuVxebCmrVkHkGnvD7QmWWNYcs7bWYYYqw6fqmEieBq kcArOOqYtDwgGKFBQo1n0iwBgu+HwOi5pGCXxV6gYiOWOVFZECFNIA3IXAarFQhZdS4M cKbUcACbEqpB+j6GUKpoMBk434TsL78pxukaZ9/r/FCCF97IHdnCnTgPkp8AZKrxrSp9 w7pVJfUD314igfaFxHK0wHVdPhanBH1623cl3Qwen53xyDxWTgEePI35BAgycGL1Rkah I4r+dosX5ivUFkrDKnZ3YJlg+bvA92oalt8nrxnhZYsX+KjKjEqQBl2d9rJFUkF9qiM0 qf1A== X-Gm-Message-State: ALoCoQnEelfj53b7GOcjCCE+G0S4U6Ocdv7DQKZK3EiXWsMCve1UYNGRx8nizPsE5Q11iRO3nYHs MIME-Version: 1.0 X-Received: by 10.194.57.40 with SMTP id f8mr9868374wjq.86.1431619641276; Thu, 14 May 2015 09:07:21 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 09:07:21 -0700 (PDT) In-Reply-To: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> Date: Thu, 14 May 2015 18:07:21 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1714099307240714019==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============1714099307240714019== Content-Type: multipart/alternative; boundary=047d7ba97b9c2c1df105160cec7b --047d7ba97b9c2c1df105160cec7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lars, sounds good, thanks! Tamas On Thu, May 14, 2015 at 5:20 PM, Lars Kurth wrote: > Looks fine to me > Unless there are further comments, I will encode this in the blog in an > hour or so > > @Tamas: I will create an account for you and publish under your name. You > will then have to reset your password > > Cheers > Lars > > > On 14 May 2015, at 14:32, Lengyel, Tamas wrote: > > =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open s= ource > enthusiast and Xen contributor. Tamas works as Senior Security Researcher > at Novetta, while finishing his PhD on the topic of malware analysis and > virtualization security at the University of Connecticut. > > ------------- > Hardening Xen against VENOM-style attacks > > > The recent disclosure of the VENOM[1] bug affecting major open-source > hypervisors, such as KVM and Xen, has been circulating in the tech news a= s > of 5/13/15, causing many to reevaluate their risks when using cloud > infrastructures. That is a very good thing indeed. Virtualization and the > cloud have been erroneously considered by many to be a silver bullet > against intrusions and malware in general. The fact is that the cloud is > anything but a safe place. There are inherent risks in the cloud, thus it > is very important to put those risks in context. > > > Hypervisors, same as any other complex software systems, are prone to bug= s > and errors. VENOM in that sense is just another one in the long list of > vulnerabilities that have been popping up against hypervisors[2]. While > VENOM is indeed a serious bug and can result in a VM escape, which in tur= n > can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fac= t, > VENOM-style attacks have been known for a long time. And there are > easy-to-deploy counter-measures to mitigate the risk of such exploits, > natively available in both Xen and KVM (see RedHat=E2=80=99s blog post on= the same > topic[3]). > > > What is the root cause of VENOM? Emulation. > > > While modern systems come with a plethora of virtualization extensions, > many components are still being emulated. The biggest component of that a= re > usually devices. Devices such as your network card, graphics card and you= r > hard drive. While Linux comes with paravirtual (virtualization-aware) > drivers to create such devices, emulation is often the only solution to r= un > operating systems that do not have such kernel drivers. This has been > traditionally the case with Windows[4]. This emulation layer has been > implemented in QEMU, which has caused VENOM and a handful of other > VM-escape bugs in recent years. However, QEMU is not the only place where > emulation is used within Xen. For a variety of interrupts and timers, suc= h > as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in > emulator in Xen itself for performance and scalability reasons[5]. As wit= h > QEMU, this emulator has been just as exploitable[6]. This is simply becau= se > to program emulating devices and services properly is really complex and > error-prone. > > > This fact, that emulation is complex and error-prone, has been known for = a > long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated > such a VM escape attack against KVM, through QEMU. The author of Virtunoi= d > even cautioned there will be many other bugs of that nature found by > researchers. Fast-forward 4 years and we now have VENOM. > > > The good news is there is an easy mitigation available for all present an= d > future QEMU bugs, also mentioned in the original Xen Security Advisory[8]= . > It is called stubdomains[9]. Stubdomains can nip the whole class of > vulnerabilities exposed by QEMU in the bud by moving QEMU into a > deprivileged domain of its own. Instead of having QEMU run as root in dom= 0, > a stubdomain has access only to the VM it is providing emulation for. Thu= s, > an escape through QEMU will only land an attacker in a stubdomain, withou= t > access to critical resources. Furthermore, QEMU in a stubdomain runs on > MiniOS, thus an attacker would only have a very limited environment to ru= n > code in (as in return-to-libc/ROP-style), having exactly the same level o= f > privilege as in the domain where the attack started. Nothing is to be > gained for a lot of work, effectively making the system as secure as it > would be if only PV drivers were used. > > > One would think it is a complex process to take advantage of this > protection, but in fact, it is very simple. Add the following line to you= r > Xen domain configuration and you gain immediate protection against VENOM, > and the whole class of vulnerabilities brought to you by QEMU: > > device_model_stubdomain_override =3D 1 > > However, as with most security systems, it comes at a cost. Running > stubdomains requires a bit of extra memory as compared to the plain QEMU > process in dom0. This in turn can limit the number of VMs a cloud provide= r > may be able to sell, thus there is limited incentive on their end to enab= le > this feature by default. Further complicating the picture is the fact tha= t > this protection works best if all VMs on the server run with stubdomains. > Otherwise you may end up protecting your neighbors against an escape atta= ck > from your domain, while not being protected from an escape attack from > theirs. It is thus no surprise if some users would not want to pay for th= is > extra protection, even if it was available. However, for private clouds a= nd > exclusive servers there is no reason why it shouldn=E2=80=99t be your def= ault > setting. > ________________ > [1] http://venom.crowdstrike.com/ > [2] http://xenbits.xen.org/xsa/ > [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. > [4] Citrix recently open-sourced its Windows PV drivers so it is no longe= r > the case: http://www.xenproject.org/downloads/windows-pv-drivers.html > [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 > [6] http://xenbits.xen.org/xsa/advisory-105.html > [7] > http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pd= f > [8] http://xenbits.xen.org/xsa/advisory-133.html > [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains > > -- > [image: www.novetta.com] > Tamas K Lengyel > Senior Security Researcher > > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --047d7ba97b9c2c1df105160cec7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lars,
sounds good, thanks!

Tamas

On Thu, May 14, 2015 at 5:20 PM, Lars Kurth <lars.kurth.xen@gmail= .com> wrote:
Looks fine to me
Unless there are further comment= s, I will encode this in the blog in an hour or so

@Tamas: I will create an account for you and publish under your name. You = will then have to reset your password

Cheers
=
Lars
=C2=A0

On 14 May 2015, at 14:32, Lengyel, Tamas <tlengyel@novetta.com> wrote:

=EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time ope= n source enthusiast and Xen contributor. Tamas works as Senior Security Res= earcher at Novetta, while finishing his PhD on the topic of malware analysi= s and virtualization security at the University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://= venom.crowdstrike.com/
[2] http://xe= nbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/ven= om-dont-get-bitten/.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv= -drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/34= 7492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/El= hage/BH_US_11_Elhage_Virtunoid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researc= her

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">
_______________________________________________
Publicity mailing listPubli= city@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/publicity

=



--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--047d7ba97b9c2c1df105160cec7b-- --===============1714099307240714019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============1714099307240714019==-- From publicity-bounces@lists.xenproject.org Thu May 14 16:07:27 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 16:07:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsvfS-0005mS-0g; Thu, 14 May 2015 16:07:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YsvfR-0005mN-9y for publicity@lists.xenproject.org; Thu, 14 May 2015 16:07:25 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 5A/BE-02776-C38C4555; Thu, 14 May 2015 16:07:24 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1431619641!15457083!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13887 invoked from network); 14 May 2015 16:07:21 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 16:07:21 -0000 Received: by wgnd10 with SMTP id d10so78223567wgn.2 for ; Thu, 14 May 2015 09:07:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/oEC/9jhbhW4ORw8LkK2aM9nob7PSwNkHNamOs07qY8=; b=Bu8NKWf3CJH5s5eN5CYG8dHjuVxebCmrVkHkGnvD7QmWWNYcs7bWYYYqw6fqmEieBq kcArOOqYtDwgGKFBQo1n0iwBgu+HwOi5pGCXxV6gYiOWOVFZECFNIA3IXAarFQhZdS4M cKbUcACbEqpB+j6GUKpoMBk434TsL78pxukaZ9/r/FCCF97IHdnCnTgPkp8AZKrxrSp9 w7pVJfUD314igfaFxHK0wHVdPhanBH1623cl3Qwen53xyDxWTgEePI35BAgycGL1Rkah I4r+dosX5ivUFkrDKnZ3YJlg+bvA92oalt8nrxnhZYsX+KjKjEqQBl2d9rJFUkF9qiM0 qf1A== X-Gm-Message-State: ALoCoQnEelfj53b7GOcjCCE+G0S4U6Ocdv7DQKZK3EiXWsMCve1UYNGRx8nizPsE5Q11iRO3nYHs MIME-Version: 1.0 X-Received: by 10.194.57.40 with SMTP id f8mr9868374wjq.86.1431619641276; Thu, 14 May 2015 09:07:21 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Thu, 14 May 2015 09:07:21 -0700 (PDT) In-Reply-To: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> Date: Thu, 14 May 2015 18:07:21 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1714099307240714019==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============1714099307240714019== Content-Type: multipart/alternative; boundary=047d7ba97b9c2c1df105160cec7b --047d7ba97b9c2c1df105160cec7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lars, sounds good, thanks! Tamas On Thu, May 14, 2015 at 5:20 PM, Lars Kurth wrote: > Looks fine to me > Unless there are further comments, I will encode this in the blog in an > hour or so > > @Tamas: I will create an account for you and publish under your name. You > will then have to reset your password > > Cheers > Lars > > > On 14 May 2015, at 14:32, Lengyel, Tamas wrote: > > =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open s= ource > enthusiast and Xen contributor. Tamas works as Senior Security Researcher > at Novetta, while finishing his PhD on the topic of malware analysis and > virtualization security at the University of Connecticut. > > ------------- > Hardening Xen against VENOM-style attacks > > > The recent disclosure of the VENOM[1] bug affecting major open-source > hypervisors, such as KVM and Xen, has been circulating in the tech news a= s > of 5/13/15, causing many to reevaluate their risks when using cloud > infrastructures. That is a very good thing indeed. Virtualization and the > cloud have been erroneously considered by many to be a silver bullet > against intrusions and malware in general. The fact is that the cloud is > anything but a safe place. There are inherent risks in the cloud, thus it > is very important to put those risks in context. > > > Hypervisors, same as any other complex software systems, are prone to bug= s > and errors. VENOM in that sense is just another one in the long list of > vulnerabilities that have been popping up against hypervisors[2]. While > VENOM is indeed a serious bug and can result in a VM escape, which in tur= n > can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fac= t, > VENOM-style attacks have been known for a long time. And there are > easy-to-deploy counter-measures to mitigate the risk of such exploits, > natively available in both Xen and KVM (see RedHat=E2=80=99s blog post on= the same > topic[3]). > > > What is the root cause of VENOM? Emulation. > > > While modern systems come with a plethora of virtualization extensions, > many components are still being emulated. The biggest component of that a= re > usually devices. Devices such as your network card, graphics card and you= r > hard drive. While Linux comes with paravirtual (virtualization-aware) > drivers to create such devices, emulation is often the only solution to r= un > operating systems that do not have such kernel drivers. This has been > traditionally the case with Windows[4]. This emulation layer has been > implemented in QEMU, which has caused VENOM and a handful of other > VM-escape bugs in recent years. However, QEMU is not the only place where > emulation is used within Xen. For a variety of interrupts and timers, suc= h > as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in > emulator in Xen itself for performance and scalability reasons[5]. As wit= h > QEMU, this emulator has been just as exploitable[6]. This is simply becau= se > to program emulating devices and services properly is really complex and > error-prone. > > > This fact, that emulation is complex and error-prone, has been known for = a > long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated > such a VM escape attack against KVM, through QEMU. The author of Virtunoi= d > even cautioned there will be many other bugs of that nature found by > researchers. Fast-forward 4 years and we now have VENOM. > > > The good news is there is an easy mitigation available for all present an= d > future QEMU bugs, also mentioned in the original Xen Security Advisory[8]= . > It is called stubdomains[9]. Stubdomains can nip the whole class of > vulnerabilities exposed by QEMU in the bud by moving QEMU into a > deprivileged domain of its own. Instead of having QEMU run as root in dom= 0, > a stubdomain has access only to the VM it is providing emulation for. Thu= s, > an escape through QEMU will only land an attacker in a stubdomain, withou= t > access to critical resources. Furthermore, QEMU in a stubdomain runs on > MiniOS, thus an attacker would only have a very limited environment to ru= n > code in (as in return-to-libc/ROP-style), having exactly the same level o= f > privilege as in the domain where the attack started. Nothing is to be > gained for a lot of work, effectively making the system as secure as it > would be if only PV drivers were used. > > > One would think it is a complex process to take advantage of this > protection, but in fact, it is very simple. Add the following line to you= r > Xen domain configuration and you gain immediate protection against VENOM, > and the whole class of vulnerabilities brought to you by QEMU: > > device_model_stubdomain_override =3D 1 > > However, as with most security systems, it comes at a cost. Running > stubdomains requires a bit of extra memory as compared to the plain QEMU > process in dom0. This in turn can limit the number of VMs a cloud provide= r > may be able to sell, thus there is limited incentive on their end to enab= le > this feature by default. Further complicating the picture is the fact tha= t > this protection works best if all VMs on the server run with stubdomains. > Otherwise you may end up protecting your neighbors against an escape atta= ck > from your domain, while not being protected from an escape attack from > theirs. It is thus no surprise if some users would not want to pay for th= is > extra protection, even if it was available. However, for private clouds a= nd > exclusive servers there is no reason why it shouldn=E2=80=99t be your def= ault > setting. > ________________ > [1] http://venom.crowdstrike.com/ > [2] http://xenbits.xen.org/xsa/ > [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. > [4] Citrix recently open-sourced its Windows PV drivers so it is no longe= r > the case: http://www.xenproject.org/downloads/windows-pv-drivers.html > [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 > [6] http://xenbits.xen.org/xsa/advisory-105.html > [7] > http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pd= f > [8] http://xenbits.xen.org/xsa/advisory-133.html > [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains > > -- > [image: www.novetta.com] > Tamas K Lengyel > Senior Security Researcher > > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > > --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --047d7ba97b9c2c1df105160cec7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lars,
sounds good, thanks!

Tamas

On Thu, May 14, 2015 at 5:20 PM, Lars Kurth <lars.kurth.xen@gmail= .com> wrote:
Looks fine to me
Unless there are further comment= s, I will encode this in the blog in an hour or so

@Tamas: I will create an account for you and publish under your name. You = will then have to reset your password

Cheers
=
Lars
=C2=A0

On 14 May 2015, at 14:32, Lengyel, Tamas <tlengyel@novetta.com> wrote:

=EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time ope= n source enthusiast and Xen contributor. Tamas works as Senior Security Res= earcher at Novetta, while finishing his PhD on the topic of malware analysi= s and virtualization security at the University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://= venom.crowdstrike.com/
[2] http://xe= nbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/ven= om-dont-get-bitten/.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv= -drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/34= 7492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/El= hage/BH_US_11_Elhage_Virtunoid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researc= her

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">
_______________________________________________
Publicity mailing listPubli= city@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/publicity

=



--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--047d7ba97b9c2c1df105160cec7b-- --===============1714099307240714019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============1714099307240714019==-- From publicity-bounces@lists.xenproject.org Thu May 14 16:45:33 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 16:45:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YswGJ-0007YO-SS; Thu, 14 May 2015 16:45:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YswGI-0007YH-Go for publicity@lists.xenproject.org; Thu, 14 May 2015 16:45:30 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id B7/55-02782-921D4555; Thu, 14 May 2015 16:45:29 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1431621926!15006746!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15222 invoked from network); 14 May 2015 16:45:26 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 16:45:26 -0000 Received: by wguv19 with SMTP id v19so19601407wgu.1 for ; Thu, 14 May 2015 09:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UAY9UHvQcHzdPWaEvqJPV7VKBWKSTH4BSxSDNDfsl48=; b=DAwxjuUlRJ8T+b0LGsLSoeggMjOX4RHVpMRORysfSDkkX3k+uA2B8ZgWkn8Sk43NAu ubTJHFcxIKmBV3GGleo6XlnsPYVitKUUV/2qjwHgqnFvUaCU5oYTk0xKklkacRMsw/B9 Q8zhk54JmlhAUK4KvcOCzuonPn+QoeFcpEcaU4oDyiIkAaKK+eNAnaR8h90YA6t4zmDU l87fYkL9KZhkaXPrweqX/FuWtnXRWzLTlcS+I7fCIRwWJ11ov093QMW46U/ahCpsnhox vDnLloWVojhTq7x4S9AYFy9g2dYSUT4J1OXauY7aoGfEFwqne8tG//GE8AOcrXnuAXbK fOsA== X-Received: by 10.180.187.232 with SMTP id fv8mr17418742wic.28.1431621926149; Thu, 14 May 2015 09:45:26 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id y7sm38993789wjw.16.2015.05.14.09.45.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 09:45:25 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 17:45:23 +0100 Message-Id: <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4395406064889418068==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============4395406064889418068== Content-Type: multipart/alternative; boundary="Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B" --Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtrue= I made some minor mods: * Inlined links * Changed link [2] to a list of vulnerabilities covering different = hypervisor technologies Sarah may go and make some minor edits. She may also add an image. We = would like to publish later tonight: if anyone one wants an additional = ACK before Sarah publishes, please let us know NOW! Regards Lars > On 14 May 2015, at 17:07, Lengyel, Tamas wrote: >=20 > Hi Lars, > sounds good, thanks! >=20 > Tamas >=20 > On Thu, May 14, 2015 at 5:20 PM, Lars Kurth > wrote: > Looks fine to me > Unless there are further comments, I will encode this in the blog in = an hour or so >=20 > @Tamas: I will create an account for you and publish under your name. = You will then have to reset your password >=20 > Cheers > Lars > =20 >=20 >> On 14 May 2015, at 14:32, Lengyel, Tamas > wrote: >>=20 >> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time = open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of = malware analysis and virtualization security at the University of = Connecticut.=20 >> =20 >> ------------- >> Hardening Xen against VENOM-style attacks=20 >> =20 >> =20 >> The recent disclosure of the VENOM[1] bug affecting major open-source = hypervisors, such as KVM and Xen, has been circulating in the tech news = as of 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.=20 >> =20 >> =20 >> Hypervisors, same as any other complex software systems, are prone to = bugs and errors. VENOM in that sense is just another one in the long = list of vulnerabilities that have been popping up against = hypervisors[2]. While VENOM is indeed a serious bug and can result in a = VM escape, which in turn can compromise all VMs on the host, it = doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known = for a long time. And there are easy-to-deploy counter-measures to = mitigate the risk of such exploits, natively available in both Xen and = KVM (see RedHat=E2=80=99s blog post on the same topic[3]).=20 >> =20 >> =20 >> What is the root cause of VENOM? Emulation.=20 >> =20 >> =20 >> While modern systems come with a plethora of virtualization = extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network = card, graphics card and your hard drive. While Linux comes with = paravirtual (virtualization-aware) drivers to create such devices, = emulation is often the only solution to run operating systems that do = not have such kernel drivers. This has been traditionally the case with = Windows[4]. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. = However, QEMU is not the only place where emulation is used within Xen. = For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, = PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. =20 >> =20 >> =20 >> This fact, that emulation is complex and error-prone, has been known = for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] = demonstrated such a VM escape attack against KVM, through QEMU. The = author of Virtunoid even cautioned there will be many other bugs of that = nature found by researchers. Fast-forward 4 years and we now have VENOM.=20= >> =20 >> =20 >> The good news is there is an easy mitigation available for all = present and future QEMU bugs, also mentioned in the original Xen = Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip = the whole class of vulnerabilities exposed by QEMU in the bud by moving = QEMU into a deprivileged domain of its own. Instead of having QEMU run = as root in dom0, a stubdomain has access only to the VM it is providing = emulation for. Thus, an escape through QEMU will only land an attacker = in a stubdomain, without access to critical resources. Furthermore, QEMU = in a stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.=20= >> =20 >> =20 >> One would think it is a complex process to take advantage of this = protection, but in fact, it is very simple. Add the following line to = your Xen domain configuration and you gain immediate protection against = VENOM, and the whole class of vulnerabilities brought to you by QEMU:=20 >>=20 >> device_model_stubdomain_override =3D 1 =20 >> =20 >> However, as with most security systems, it comes at a cost. Running = stubdomains requires a bit of extra memory as compared to the plain QEMU = process in dom0. This in turn can limit the number of VMs a cloud = provider may be able to sell, thus there is limited incentive on their = end to enable this feature by default. Further complicating the picture = is the fact that this protection works best if all VMs on the server run = with stubdomains. Otherwise you may end up protecting your neighbors = against an escape attack from your domain, while not being protected = from an escape attack from theirs. It is thus no surprise if some users = would not want to pay for this extra protection, even if it was = available. However, for private clouds and exclusive servers there is no = reason why it shouldn=E2=80=99t be your default setting. =20 >> ________________=20 >> [1] http://venom.crowdstrike.com/ =20 >> [2] http://xenbits.xen.org/xsa/ =20 >> [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/ = .=20 >> [4] Citrix recently open-sourced its Windows PV drivers so it is no = longer the case: = http://www.xenproject.org/downloads/windows-pv-drivers.html = =20 >> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 = =20 >> [6] http://xenbits.xen.org/xsa/advisory-105.html = =20 >> [7] = http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf= = =20 >> [8] http://xenbits.xen.org/xsa/advisory-133.html = =20 >> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains = >>=20 >> --=20 >> =20 >> Tamas K Lengyel >> Senior Security Researcher >>=20 >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com = _______________________________________________ >> Publicity mailing list >> Publicity@lists.xenproject.org = >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity = >=20 >=20 >=20 >=20 > --=20 > =20 > Tamas K Lengyel > Senior Security Researcher >=20 > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com --Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

the= draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtrue
I made some minor mods:
* = Inlined links
* Changed link [2] to a list of = vulnerabilities covering different hypervisor technologies

Sarah may go and make = some minor edits. She may also add an image. We would like to publish = later tonight: if anyone one wants an additional ACK before Sarah = publishes, please let us know NOW!

Regards
Lars

On 14 May 2015, at 17:07, = Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tamas

On Thu, May 14, 2015 at 5:20 PM, = Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Looks fine to me
Unless there are further comments, I will encode this in the = blog in an hour or so

@Tamas: I will create an account for you and publish under = your name. You will then have to reset your password

Cheers
Lars
 

On 14 May 2015, at 14:32, = Lengyel, Tamas <tlengyel@novetta.com> = wrote:

=EF=BB=BFThis = is a guest blog post by Tamas K Lengyel, a long-time open source = enthusiast and Xen contributor. Tamas works as Senior Security = Researcher at Novetta, while finishing his PhD on the topic of malware = analysis and virtualization security at the University of Connecticut.
 
-------------
Hardening = Xen against VENOM-style attacks
 
 
The recent = disclosure of the VENOM[1] bug affecting major open-source hypervisors, = such as KVM and Xen, has been circulating in the tech news as of = 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.
 
 
Hypervisors, = same as any other complex software systems, are prone to bugs and = errors. VENOM in that sense is just another one in the long list of = vulnerabilities that have been popping up against hypervisors[2]. While = VENOM is indeed a serious bug and can result in a VM escape, which in = turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. = In fact, VENOM-style attacks have been known for a long time. And there = are easy-to-deploy counter-measures to mitigate the risk of such = exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s = blog post on the same topic[3]).
 
 
What is the = root cause of VENOM? Emulation.
 
 
While modern = systems come with a plethora of virtualization extensions, many = components are still being emulated. The biggest component of that are = usually devices. Devices such as your network card, graphics card and = your hard drive. While Linux comes with paravirtual = (virtualization-aware) drivers to create such devices, emulation is = often the only solution to run operating systems that do not have such = kernel drivers. This has been traditionally the case with Windows[4]. = This emulation layer has been implemented in QEMU, which has caused = VENOM and a handful of other VM-escape bugs in recent years. However, = QEMU is not the only place where emulation is used within Xen. For a = variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, = IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. 
 
 
This fact, that = emulation is complex and error-prone, has been known for a long time. = Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM = escape attack against KVM, through QEMU. The author of Virtunoid even = cautioned there will be many other bugs of that nature found by = researchers. Fast-forward 4 years and we now have VENOM.
 
 
The good news = is there is an easy mitigation available for all present and future QEMU = bugs, also mentioned in the original Xen Security Advisory[8]. It is = called stubdomains[9]. Stubdomains can nip the whole class of = vulnerabilities exposed by QEMU in the bud by moving QEMU into a = deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.
 
 
One would think = it is a complex process to take advantage of this protection, but in = fact, it is very simple. Add the following line to your Xen domain = configuration and you gain immediate protection against VENOM, and the = whole class of vulnerabilities brought to you by QEMU:

device_model_stubdomain_override =3D = 1 
 
However, as with most security = systems, it comes at a cost. Running stubdomains requires a bit of extra = memory as compared to the plain QEMU process in dom0. This in turn can = limit the number of VMs a cloud provider may be able to sell, thus there = is limited incentive on their end to enable this feature by default. = Further complicating the picture is the fact that this protection works = best if all VMs on the server run with stubdomains. Otherwise you may = end up protecting your neighbors against an escape attack from your = domain, while not being protected from an escape attack from theirs. It = is thus no surprise if some users would not want to pay for this extra = protection, even if it was available. However, for private clouds and = exclusive servers there is no reason why it shouldn=E2=80=99t be your = default setting. 
________________
[1] http://venom.crowdstrike.com/
[2] http://xenbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitte= n/.
[4] Citrix recently open-sourced its Windows PV drivers = so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html=
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtu= noid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= /a>




--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com

= --Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B-- --===============4395406064889418068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============4395406064889418068==-- From publicity-bounces@lists.xenproject.org Thu May 14 16:45:33 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 14 May 2015 16:45:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YswGJ-0007YO-SS; Thu, 14 May 2015 16:45:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YswGI-0007YH-Go for publicity@lists.xenproject.org; Thu, 14 May 2015 16:45:30 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id B7/55-02782-921D4555; Thu, 14 May 2015 16:45:29 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1431621926!15006746!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15222 invoked from network); 14 May 2015 16:45:26 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 May 2015 16:45:26 -0000 Received: by wguv19 with SMTP id v19so19601407wgu.1 for ; Thu, 14 May 2015 09:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UAY9UHvQcHzdPWaEvqJPV7VKBWKSTH4BSxSDNDfsl48=; b=DAwxjuUlRJ8T+b0LGsLSoeggMjOX4RHVpMRORysfSDkkX3k+uA2B8ZgWkn8Sk43NAu ubTJHFcxIKmBV3GGleo6XlnsPYVitKUUV/2qjwHgqnFvUaCU5oYTk0xKklkacRMsw/B9 Q8zhk54JmlhAUK4KvcOCzuonPn+QoeFcpEcaU4oDyiIkAaKK+eNAnaR8h90YA6t4zmDU l87fYkL9KZhkaXPrweqX/FuWtnXRWzLTlcS+I7fCIRwWJ11ov093QMW46U/ahCpsnhox vDnLloWVojhTq7x4S9AYFy9g2dYSUT4J1OXauY7aoGfEFwqne8tG//GE8AOcrXnuAXbK fOsA== X-Received: by 10.180.187.232 with SMTP id fv8mr17418742wic.28.1431621926149; Thu, 14 May 2015 09:45:26 -0700 (PDT) Received: from dhcp-3-49.uk.xensource.com ([185.25.64.249]) by mx.google.com with ESMTPSA id y7sm38993789wjw.16.2015.05.14.09.45.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 09:45:25 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: Date: Thu, 14 May 2015 17:45:23 +0100 Message-Id: <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4395406064889418068==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============4395406064889418068== Content-Type: multipart/alternative; boundary="Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B" --Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtrue= I made some minor mods: * Inlined links * Changed link [2] to a list of vulnerabilities covering different = hypervisor technologies Sarah may go and make some minor edits. She may also add an image. We = would like to publish later tonight: if anyone one wants an additional = ACK before Sarah publishes, please let us know NOW! Regards Lars > On 14 May 2015, at 17:07, Lengyel, Tamas wrote: >=20 > Hi Lars, > sounds good, thanks! >=20 > Tamas >=20 > On Thu, May 14, 2015 at 5:20 PM, Lars Kurth > wrote: > Looks fine to me > Unless there are further comments, I will encode this in the blog in = an hour or so >=20 > @Tamas: I will create an account for you and publish under your name. = You will then have to reset your password >=20 > Cheers > Lars > =20 >=20 >> On 14 May 2015, at 14:32, Lengyel, Tamas > wrote: >>=20 >> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time = open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of = malware analysis and virtualization security at the University of = Connecticut.=20 >> =20 >> ------------- >> Hardening Xen against VENOM-style attacks=20 >> =20 >> =20 >> The recent disclosure of the VENOM[1] bug affecting major open-source = hypervisors, such as KVM and Xen, has been circulating in the tech news = as of 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.=20 >> =20 >> =20 >> Hypervisors, same as any other complex software systems, are prone to = bugs and errors. VENOM in that sense is just another one in the long = list of vulnerabilities that have been popping up against = hypervisors[2]. While VENOM is indeed a serious bug and can result in a = VM escape, which in turn can compromise all VMs on the host, it = doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known = for a long time. And there are easy-to-deploy counter-measures to = mitigate the risk of such exploits, natively available in both Xen and = KVM (see RedHat=E2=80=99s blog post on the same topic[3]).=20 >> =20 >> =20 >> What is the root cause of VENOM? Emulation.=20 >> =20 >> =20 >> While modern systems come with a plethora of virtualization = extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network = card, graphics card and your hard drive. While Linux comes with = paravirtual (virtualization-aware) drivers to create such devices, = emulation is often the only solution to run operating systems that do = not have such kernel drivers. This has been traditionally the case with = Windows[4]. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. = However, QEMU is not the only place where emulation is used within Xen. = For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, = PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. =20 >> =20 >> =20 >> This fact, that emulation is complex and error-prone, has been known = for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] = demonstrated such a VM escape attack against KVM, through QEMU. The = author of Virtunoid even cautioned there will be many other bugs of that = nature found by researchers. Fast-forward 4 years and we now have VENOM.=20= >> =20 >> =20 >> The good news is there is an easy mitigation available for all = present and future QEMU bugs, also mentioned in the original Xen = Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip = the whole class of vulnerabilities exposed by QEMU in the bud by moving = QEMU into a deprivileged domain of its own. Instead of having QEMU run = as root in dom0, a stubdomain has access only to the VM it is providing = emulation for. Thus, an escape through QEMU will only land an attacker = in a stubdomain, without access to critical resources. Furthermore, QEMU = in a stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.=20= >> =20 >> =20 >> One would think it is a complex process to take advantage of this = protection, but in fact, it is very simple. Add the following line to = your Xen domain configuration and you gain immediate protection against = VENOM, and the whole class of vulnerabilities brought to you by QEMU:=20 >>=20 >> device_model_stubdomain_override =3D 1 =20 >> =20 >> However, as with most security systems, it comes at a cost. Running = stubdomains requires a bit of extra memory as compared to the plain QEMU = process in dom0. This in turn can limit the number of VMs a cloud = provider may be able to sell, thus there is limited incentive on their = end to enable this feature by default. Further complicating the picture = is the fact that this protection works best if all VMs on the server run = with stubdomains. Otherwise you may end up protecting your neighbors = against an escape attack from your domain, while not being protected = from an escape attack from theirs. It is thus no surprise if some users = would not want to pay for this extra protection, even if it was = available. However, for private clouds and exclusive servers there is no = reason why it shouldn=E2=80=99t be your default setting. =20 >> ________________=20 >> [1] http://venom.crowdstrike.com/ =20 >> [2] http://xenbits.xen.org/xsa/ =20 >> [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/ = .=20 >> [4] Citrix recently open-sourced its Windows PV drivers so it is no = longer the case: = http://www.xenproject.org/downloads/windows-pv-drivers.html = =20 >> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 = =20 >> [6] http://xenbits.xen.org/xsa/advisory-105.html = =20 >> [7] = http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf= = =20 >> [8] http://xenbits.xen.org/xsa/advisory-133.html = =20 >> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains = >>=20 >> --=20 >> =20 >> Tamas K Lengyel >> Senior Security Researcher >>=20 >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com = _______________________________________________ >> Publicity mailing list >> Publicity@lists.xenproject.org = >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity = >=20 >=20 >=20 >=20 > --=20 > =20 > Tamas K Lengyel > Senior Security Researcher >=20 > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com --Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

the= draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtrue
I made some minor mods:
* = Inlined links
* Changed link [2] to a list of = vulnerabilities covering different hypervisor technologies

Sarah may go and make = some minor edits. She may also add an image. We would like to publish = later tonight: if anyone one wants an additional ACK before Sarah = publishes, please let us know NOW!

Regards
Lars

On 14 May 2015, at 17:07, = Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tamas

On Thu, May 14, 2015 at 5:20 PM, = Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Looks fine to me
Unless there are further comments, I will encode this in the = blog in an hour or so

@Tamas: I will create an account for you and publish under = your name. You will then have to reset your password

Cheers
Lars
 

On 14 May 2015, at 14:32, = Lengyel, Tamas <tlengyel@novetta.com> = wrote:

=EF=BB=BFThis = is a guest blog post by Tamas K Lengyel, a long-time open source = enthusiast and Xen contributor. Tamas works as Senior Security = Researcher at Novetta, while finishing his PhD on the topic of malware = analysis and virtualization security at the University of Connecticut.
 
-------------
Hardening = Xen against VENOM-style attacks
 
 
The recent = disclosure of the VENOM[1] bug affecting major open-source hypervisors, = such as KVM and Xen, has been circulating in the tech news as of = 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.
 
 
Hypervisors, = same as any other complex software systems, are prone to bugs and = errors. VENOM in that sense is just another one in the long list of = vulnerabilities that have been popping up against hypervisors[2]. While = VENOM is indeed a serious bug and can result in a VM escape, which in = turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. = In fact, VENOM-style attacks have been known for a long time. And there = are easy-to-deploy counter-measures to mitigate the risk of such = exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s = blog post on the same topic[3]).
 
 
What is the = root cause of VENOM? Emulation.
 
 
While modern = systems come with a plethora of virtualization extensions, many = components are still being emulated. The biggest component of that are = usually devices. Devices such as your network card, graphics card and = your hard drive. While Linux comes with paravirtual = (virtualization-aware) drivers to create such devices, emulation is = often the only solution to run operating systems that do not have such = kernel drivers. This has been traditionally the case with Windows[4]. = This emulation layer has been implemented in QEMU, which has caused = VENOM and a handful of other VM-escape bugs in recent years. However, = QEMU is not the only place where emulation is used within Xen. For a = variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, = IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. 
 
 
This fact, that = emulation is complex and error-prone, has been known for a long time. = Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM = escape attack against KVM, through QEMU. The author of Virtunoid even = cautioned there will be many other bugs of that nature found by = researchers. Fast-forward 4 years and we now have VENOM.
 
 
The good news = is there is an easy mitigation available for all present and future QEMU = bugs, also mentioned in the original Xen Security Advisory[8]. It is = called stubdomains[9]. Stubdomains can nip the whole class of = vulnerabilities exposed by QEMU in the bud by moving QEMU into a = deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.
 
 
One would think = it is a complex process to take advantage of this protection, but in = fact, it is very simple. Add the following line to your Xen domain = configuration and you gain immediate protection against VENOM, and the = whole class of vulnerabilities brought to you by QEMU:

device_model_stubdomain_override =3D = 1 
 
However, as with most security = systems, it comes at a cost. Running stubdomains requires a bit of extra = memory as compared to the plain QEMU process in dom0. This in turn can = limit the number of VMs a cloud provider may be able to sell, thus there = is limited incentive on their end to enable this feature by default. = Further complicating the picture is the fact that this protection works = best if all VMs on the server run with stubdomains. Otherwise you may = end up protecting your neighbors against an escape attack from your = domain, while not being protected from an escape attack from theirs. It = is thus no surprise if some users would not want to pay for this extra = protection, even if it was available. However, for private clouds and = exclusive servers there is no reason why it shouldn=E2=80=99t be your = default setting. 
________________
[1] http://venom.crowdstrike.com/
[2] http://xenbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitte= n/.
[4] Citrix recently open-sourced its Windows PV drivers = so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html=
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtu= noid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= /a>




--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com

= --Apple-Mail=_62574BD0-2456-4ED9-87F7-ED7B042A031B-- --===============4395406064889418068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============4395406064889418068==-- From publicity-bounces@lists.xenproject.org Fri May 15 08:39:34 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 15 May 2015 08:39:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtB9a-0006Qq-6v; Fri, 15 May 2015 08:39:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtB9Z-0006Qi-2P for publicity@lists.xenproject.org; Fri, 15 May 2015 08:39:33 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C7/FF-03028-4C0B5555; Fri, 15 May 2015 08:39:32 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1431679169!10806058!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19934 invoked from network); 15 May 2015 08:39:29 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 May 2015 08:39:29 -0000 Received: by wgbhc8 with SMTP id hc8so71244055wgb.3 for ; Fri, 15 May 2015 01:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XQtHlWVnfRYLWGo6rxWmlx11efzj7FoO1FiM89eSz5g=; b=aNySFfChB40L+Of9xhDj1sQ+AY3+A2L0Ask+NDpegwZ0Ou2dmXKLgOt8J+X8OuolT2 I9PBiZhspP4VRyqIxrwgI0Hl9JDGol0jn7TG8tk27ZF/TnHLqjy+R8Yu7oMYQiS9T8Ct 6tYmQHl1wmS2KOEGJu7Jkt+Jc2aCyI/icKxelkb6hTYP8YKmtbErkBhq+wvHbHerWt5J 55KYKnYmVT2hG+f2G6WzP7enpdjeCYrhBEeGTwenAF0yAI4NE/SIko//njO98J1KEFxg VwSSAfSqGAkUdXPrFjyGTPEaac7cLvSJx2w5sPtAdCvs+og1hUxYtkS10s79NFyG/Es3 Lu7A== X-Received: by 10.180.80.197 with SMTP id t5mr56036125wix.63.1431679168672; Fri, 15 May 2015 01:39:28 -0700 (PDT) Received: from [192.168.0.8] (97e3cdda.skybroadband.com. [151.227.205.218]) by mx.google.com with ESMTPSA id gj7sm2165478wib.4.2015.05.15.01.39.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 May 2015 01:39:27 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> Date: Fri, 15 May 2015 09:39:25 +0100 Message-Id: References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1963944387044006362==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============1963944387044006362== Content-Type: multipart/alternative; boundary="Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6" --Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tamas, Sarah was making some minor changes. Please go to = https://blog.xenproject.org/?p=3D10701&preview=3Dtrue = and log in via = tlengyel and let us know whether we are ready to publish. We probably = want to do this around noon UK time Lars > On 14 May 2015, at 17:45, Lars Kurth wrote: >=20 > Hi all, >=20 > the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtr= ue > I made some minor mods: > * Inlined links > * Changed link [2] to a list of vulnerabilities covering different = hypervisor technologies >=20 > Sarah may go and make some minor edits. She may also add an image. We = would like to publish later tonight: if anyone one wants an additional = ACK before Sarah publishes, please let us know NOW! >=20 > Regards > Lars >=20 >> On 14 May 2015, at 17:07, Lengyel, Tamas > wrote: >>=20 >> Hi Lars, >> sounds good, thanks! >>=20 >> Tamas >>=20 >> On Thu, May 14, 2015 at 5:20 PM, Lars Kurth > wrote: >> Looks fine to me >> Unless there are further comments, I will encode this in the blog in = an hour or so >>=20 >> @Tamas: I will create an account for you and publish under your name. = You will then have to reset your password >>=20 >> Cheers >> Lars >> =20 >>=20 >>> On 14 May 2015, at 14:32, Lengyel, Tamas > wrote: >>>=20 >>> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time = open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of = malware analysis and virtualization security at the University of = Connecticut.=20 >>> =20 >>> ------------- >>> Hardening Xen against VENOM-style attacks=20 >>> =20 >>> =20 >>> The recent disclosure of the VENOM[1] bug affecting major = open-source hypervisors, such as KVM and Xen, has been circulating in = the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. = Virtualization and the cloud have been erroneously considered by many to = be a silver bullet against intrusions and malware in general. The fact = is that the cloud is anything but a safe place. There are inherent risks = in the cloud, thus it is very important to put those risks in context.=20= >>> =20 >>> =20 >>> Hypervisors, same as any other complex software systems, are prone = to bugs and errors. VENOM in that sense is just another one in the long = list of vulnerabilities that have been popping up against = hypervisors[2]. While VENOM is indeed a serious bug and can result in a = VM escape, which in turn can compromise all VMs on the host, it = doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known = for a long time. And there are easy-to-deploy counter-measures to = mitigate the risk of such exploits, natively available in both Xen and = KVM (see RedHat=E2=80=99s blog post on the same topic[3]).=20 >>> =20 >>> =20 >>> What is the root cause of VENOM? Emulation.=20 >>> =20 >>> =20 >>> While modern systems come with a plethora of virtualization = extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network = card, graphics card and your hard drive. While Linux comes with = paravirtual (virtualization-aware) drivers to create such devices, = emulation is often the only solution to run operating systems that do = not have such kernel drivers. This has been traditionally the case with = Windows[4]. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. = However, QEMU is not the only place where emulation is used within Xen. = For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, = PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. =20 >>> =20 >>> =20 >>> This fact, that emulation is complex and error-prone, has been known = for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] = demonstrated such a VM escape attack against KVM, through QEMU. The = author of Virtunoid even cautioned there will be many other bugs of that = nature found by researchers. Fast-forward 4 years and we now have VENOM.=20= >>> =20 >>> =20 >>> The good news is there is an easy mitigation available for all = present and future QEMU bugs, also mentioned in the original Xen = Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip = the whole class of vulnerabilities exposed by QEMU in the bud by moving = QEMU into a deprivileged domain of its own. Instead of having QEMU run = as root in dom0, a stubdomain has access only to the VM it is providing = emulation for. Thus, an escape through QEMU will only land an attacker = in a stubdomain, without access to critical resources. Furthermore, QEMU = in a stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.=20= >>> =20 >>> =20 >>> One would think it is a complex process to take advantage of this = protection, but in fact, it is very simple. Add the following line to = your Xen domain configuration and you gain immediate protection against = VENOM, and the whole class of vulnerabilities brought to you by QEMU:=20 >>>=20 >>> device_model_stubdomain_override =3D 1 =20 >>> =20 >>> However, as with most security systems, it comes at a cost. Running = stubdomains requires a bit of extra memory as compared to the plain QEMU = process in dom0. This in turn can limit the number of VMs a cloud = provider may be able to sell, thus there is limited incentive on their = end to enable this feature by default. Further complicating the picture = is the fact that this protection works best if all VMs on the server run = with stubdomains. Otherwise you may end up protecting your neighbors = against an escape attack from your domain, while not being protected = from an escape attack from theirs. It is thus no surprise if some users = would not want to pay for this extra protection, even if it was = available. However, for private clouds and exclusive servers there is no = reason why it shouldn=E2=80=99t be your default setting. =20 >>> ________________=20 >>> [1] http://venom.crowdstrike.com/ =20 >>> [2] http://xenbits.xen.org/xsa/ =20 >>> [3] = https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/ = .=20 >>> [4] Citrix recently open-sourced its Windows PV drivers so it is no = longer the case: = http://www.xenproject.org/downloads/windows-pv-drivers.html = =20 >>> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 = =20 >>> [6] http://xenbits.xen.org/xsa/advisory-105.html = =20 >>> [7] = http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf= = =20 >>> [8] http://xenbits.xen.org/xsa/advisory-133.html = =20 >>> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains = >>>=20 >>> --=20 >>> =20 >>> Tamas K Lengyel >>> Senior Security Researcher >>>=20 >>> 7921 Jones Branch Drive >>> McLean VA 22102 >>> Email tlengyel@novetta.com = _______________________________________________ >>> Publicity mailing list >>> Publicity@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity = >>=20 >>=20 >>=20 >>=20 >> --=20 >> =20 >> Tamas K Lengyel >> Senior Security Researcher >>=20 >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com --Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tamas,
Sarah was making some minor changes. = Please go to https://blog.xenproject.org/?p=3D10701&preview=3Dtrue&n= bsp;and log in via tlengyel and let us know whether we are ready to = publish. We probably want to do this around noon UK time
Lars

On 14 May 2015, at 17:45, Lars = Kurth <lars.kurth.xen@gmail.com> wrote:

Hi all,

the draft most is = at https://blog.xenproject.org/?p=3D10701&preview=3Dtrue
I made some minor mods:
* = Inlined links
* Changed link [2] to a list of = vulnerabilities covering different hypervisor technologies

Sarah may go and make = some minor edits. She may also add an image. We would like to publish = later tonight: if anyone one wants an additional ACK before Sarah = publishes, please let us know NOW!

Regards
Lars

On 14 = May 2015, at 17:07, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tamas

On Thu, May 14, 2015 at 5:20 PM, = Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Looks fine to me
Unless there are further comments, I will encode this in the = blog in an hour or so

@Tamas: I will create an account for you and publish under = your name. You will then have to reset your password

Cheers
Lars
 

On 14 May 2015, at 14:32, = Lengyel, Tamas <tlengyel@novetta.com> = wrote:

=EF=BB=BFThis = is a guest blog post by Tamas K Lengyel, a long-time open source = enthusiast and Xen contributor. Tamas works as Senior Security = Researcher at Novetta, while finishing his PhD on the topic of malware = analysis and virtualization security at the University of Connecticut.
 
-------------
Hardening = Xen against VENOM-style attacks
 
 
The recent = disclosure of the VENOM[1] bug affecting major open-source hypervisors, = such as KVM and Xen, has been circulating in the tech news as of = 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.
 
 
Hypervisors, = same as any other complex software systems, are prone to bugs and = errors. VENOM in that sense is just another one in the long list of = vulnerabilities that have been popping up against hypervisors[2]. While = VENOM is indeed a serious bug and can result in a VM escape, which in = turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. = In fact, VENOM-style attacks have been known for a long time. And there = are easy-to-deploy counter-measures to mitigate the risk of such = exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s = blog post on the same topic[3]).
 
 
What is the = root cause of VENOM? Emulation.
 
 
While modern = systems come with a plethora of virtualization extensions, many = components are still being emulated. The biggest component of that are = usually devices. Devices such as your network card, graphics card and = your hard drive. While Linux comes with paravirtual = (virtualization-aware) drivers to create such devices, emulation is = often the only solution to run operating systems that do not have such = kernel drivers. This has been traditionally the case with Windows[4]. = This emulation layer has been implemented in QEMU, which has caused = VENOM and a handful of other VM-escape bugs in recent years. However, = QEMU is not the only place where emulation is used within Xen. For a = variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, = IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. 
 
 
This fact, that = emulation is complex and error-prone, has been known for a long time. = Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM = escape attack against KVM, through QEMU. The author of Virtunoid even = cautioned there will be many other bugs of that nature found by = researchers. Fast-forward 4 years and we now have VENOM.
 
 
The good news = is there is an easy mitigation available for all present and future QEMU = bugs, also mentioned in the original Xen Security Advisory[8]. It is = called stubdomains[9]. Stubdomains can nip the whole class of = vulnerabilities exposed by QEMU in the bud by moving QEMU into a = deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.
 
 
One would think = it is a complex process to take advantage of this protection, but in = fact, it is very simple. Add the following line to your Xen domain = configuration and you gain immediate protection against VENOM, and the = whole class of vulnerabilities brought to you by QEMU:

device_model_stubdomain_override =3D = 1 
 
However, as with most security = systems, it comes at a cost. Running stubdomains requires a bit of extra = memory as compared to the plain QEMU process in dom0. This in turn can = limit the number of VMs a cloud provider may be able to sell, thus there = is limited incentive on their end to enable this feature by default. = Further complicating the picture is the fact that this protection works = best if all VMs on the server run with stubdomains. Otherwise you may = end up protecting your neighbors against an escape attack from your = domain, while not being protected from an escape attack from theirs. It = is thus no surprise if some users would not want to pay for this extra = protection, even if it was available. However, for private clouds and = exclusive servers there is no reason why it shouldn=E2=80=99t be your = default setting. 
________________
[1] http://venom.crowdstrike.com/
[2] http://xenbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitte= n/.
[4] Citrix recently open-sourced its Windows PV drivers = so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html=
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtu= noid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= /a>




--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com


= --Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6-- --===============1963944387044006362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============1963944387044006362==-- From publicity-bounces@lists.xenproject.org Fri May 15 08:39:34 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 15 May 2015 08:39:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtB9a-0006Qq-6v; Fri, 15 May 2015 08:39:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtB9Z-0006Qi-2P for publicity@lists.xenproject.org; Fri, 15 May 2015 08:39:33 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id C7/FF-03028-4C0B5555; Fri, 15 May 2015 08:39:32 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1431679169!10806058!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19934 invoked from network); 15 May 2015 08:39:29 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-5.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 May 2015 08:39:29 -0000 Received: by wgbhc8 with SMTP id hc8so71244055wgb.3 for ; Fri, 15 May 2015 01:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XQtHlWVnfRYLWGo6rxWmlx11efzj7FoO1FiM89eSz5g=; b=aNySFfChB40L+Of9xhDj1sQ+AY3+A2L0Ask+NDpegwZ0Ou2dmXKLgOt8J+X8OuolT2 I9PBiZhspP4VRyqIxrwgI0Hl9JDGol0jn7TG8tk27ZF/TnHLqjy+R8Yu7oMYQiS9T8Ct 6tYmQHl1wmS2KOEGJu7Jkt+Jc2aCyI/icKxelkb6hTYP8YKmtbErkBhq+wvHbHerWt5J 55KYKnYmVT2hG+f2G6WzP7enpdjeCYrhBEeGTwenAF0yAI4NE/SIko//njO98J1KEFxg VwSSAfSqGAkUdXPrFjyGTPEaac7cLvSJx2w5sPtAdCvs+og1hUxYtkS10s79NFyG/Es3 Lu7A== X-Received: by 10.180.80.197 with SMTP id t5mr56036125wix.63.1431679168672; Fri, 15 May 2015 01:39:28 -0700 (PDT) Received: from [192.168.0.8] (97e3cdda.skybroadband.com. [151.227.205.218]) by mx.google.com with ESMTPSA id gj7sm2165478wib.4.2015.05.15.01.39.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 May 2015 01:39:27 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Lars Kurth In-Reply-To: <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> Date: Fri, 15 May 2015 09:39:25 +0100 Message-Id: References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2098) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1963944387044006362==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============1963944387044006362== Content-Type: multipart/alternative; boundary="Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6" --Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tamas, Sarah was making some minor changes. Please go to = https://blog.xenproject.org/?p=3D10701&preview=3Dtrue = and log in via = tlengyel and let us know whether we are ready to publish. We probably = want to do this around noon UK time Lars > On 14 May 2015, at 17:45, Lars Kurth wrote: >=20 > Hi all, >=20 > the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtr= ue > I made some minor mods: > * Inlined links > * Changed link [2] to a list of vulnerabilities covering different = hypervisor technologies >=20 > Sarah may go and make some minor edits. She may also add an image. We = would like to publish later tonight: if anyone one wants an additional = ACK before Sarah publishes, please let us know NOW! >=20 > Regards > Lars >=20 >> On 14 May 2015, at 17:07, Lengyel, Tamas > wrote: >>=20 >> Hi Lars, >> sounds good, thanks! >>=20 >> Tamas >>=20 >> On Thu, May 14, 2015 at 5:20 PM, Lars Kurth > wrote: >> Looks fine to me >> Unless there are further comments, I will encode this in the blog in = an hour or so >>=20 >> @Tamas: I will create an account for you and publish under your name. = You will then have to reset your password >>=20 >> Cheers >> Lars >> =20 >>=20 >>> On 14 May 2015, at 14:32, Lengyel, Tamas > wrote: >>>=20 >>> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time = open source enthusiast and Xen contributor. Tamas works as Senior = Security Researcher at Novetta, while finishing his PhD on the topic of = malware analysis and virtualization security at the University of = Connecticut.=20 >>> =20 >>> ------------- >>> Hardening Xen against VENOM-style attacks=20 >>> =20 >>> =20 >>> The recent disclosure of the VENOM[1] bug affecting major = open-source hypervisors, such as KVM and Xen, has been circulating in = the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. = Virtualization and the cloud have been erroneously considered by many to = be a silver bullet against intrusions and malware in general. The fact = is that the cloud is anything but a safe place. There are inherent risks = in the cloud, thus it is very important to put those risks in context.=20= >>> =20 >>> =20 >>> Hypervisors, same as any other complex software systems, are prone = to bugs and errors. VENOM in that sense is just another one in the long = list of vulnerabilities that have been popping up against = hypervisors[2]. While VENOM is indeed a serious bug and can result in a = VM escape, which in turn can compromise all VMs on the host, it = doesn=E2=80=99t have to be. In fact, VENOM-style attacks have been known = for a long time. And there are easy-to-deploy counter-measures to = mitigate the risk of such exploits, natively available in both Xen and = KVM (see RedHat=E2=80=99s blog post on the same topic[3]).=20 >>> =20 >>> =20 >>> What is the root cause of VENOM? Emulation.=20 >>> =20 >>> =20 >>> While modern systems come with a plethora of virtualization = extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network = card, graphics card and your hard drive. While Linux comes with = paravirtual (virtualization-aware) drivers to create such devices, = emulation is often the only solution to run operating systems that do = not have such kernel drivers. This has been traditionally the case with = Windows[4]. This emulation layer has been implemented in QEMU, which has = caused VENOM and a handful of other VM-escape bugs in recent years. = However, QEMU is not the only place where emulation is used within Xen. = For a variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, = PIC, IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. =20 >>> =20 >>> =20 >>> This fact, that emulation is complex and error-prone, has been known = for a long time. Back in 2011, the Blackhat talk on Virtunoid[7] = demonstrated such a VM escape attack against KVM, through QEMU. The = author of Virtunoid even cautioned there will be many other bugs of that = nature found by researchers. Fast-forward 4 years and we now have VENOM.=20= >>> =20 >>> =20 >>> The good news is there is an easy mitigation available for all = present and future QEMU bugs, also mentioned in the original Xen = Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip = the whole class of vulnerabilities exposed by QEMU in the bud by moving = QEMU into a deprivileged domain of its own. Instead of having QEMU run = as root in dom0, a stubdomain has access only to the VM it is providing = emulation for. Thus, an escape through QEMU will only land an attacker = in a stubdomain, without access to critical resources. Furthermore, QEMU = in a stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.=20= >>> =20 >>> =20 >>> One would think it is a complex process to take advantage of this = protection, but in fact, it is very simple. Add the following line to = your Xen domain configuration and you gain immediate protection against = VENOM, and the whole class of vulnerabilities brought to you by QEMU:=20 >>>=20 >>> device_model_stubdomain_override =3D 1 =20 >>> =20 >>> However, as with most security systems, it comes at a cost. Running = stubdomains requires a bit of extra memory as compared to the plain QEMU = process in dom0. This in turn can limit the number of VMs a cloud = provider may be able to sell, thus there is limited incentive on their = end to enable this feature by default. Further complicating the picture = is the fact that this protection works best if all VMs on the server run = with stubdomains. Otherwise you may end up protecting your neighbors = against an escape attack from your domain, while not being protected = from an escape attack from theirs. It is thus no surprise if some users = would not want to pay for this extra protection, even if it was = available. However, for private clouds and exclusive servers there is no = reason why it shouldn=E2=80=99t be your default setting. =20 >>> ________________=20 >>> [1] http://venom.crowdstrike.com/ =20 >>> [2] http://xenbits.xen.org/xsa/ =20 >>> [3] = https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/ = .=20 >>> [4] Citrix recently open-sourced its Windows PV drivers so it is no = longer the case: = http://www.xenproject.org/downloads/windows-pv-drivers.html = =20 >>> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 = =20 >>> [6] http://xenbits.xen.org/xsa/advisory-105.html = =20 >>> [7] = http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf= = =20 >>> [8] http://xenbits.xen.org/xsa/advisory-133.html = =20 >>> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains = >>>=20 >>> --=20 >>> =20 >>> Tamas K Lengyel >>> Senior Security Researcher >>>=20 >>> 7921 Jones Branch Drive >>> McLean VA 22102 >>> Email tlengyel@novetta.com = _______________________________________________ >>> Publicity mailing list >>> Publicity@lists.xenproject.org = >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity = >>=20 >>=20 >>=20 >>=20 >> --=20 >> =20 >> Tamas K Lengyel >> Senior Security Researcher >>=20 >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com --Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tamas,
Sarah was making some minor changes. = Please go to https://blog.xenproject.org/?p=3D10701&preview=3Dtrue&n= bsp;and log in via tlengyel and let us know whether we are ready to = publish. We probably want to do this around noon UK time
Lars

On 14 May 2015, at 17:45, Lars = Kurth <lars.kurth.xen@gmail.com> wrote:

Hi all,

the draft most is = at https://blog.xenproject.org/?p=3D10701&preview=3Dtrue
I made some minor mods:
* = Inlined links
* Changed link [2] to a list of = vulnerabilities covering different hypervisor technologies

Sarah may go and make = some minor edits. She may also add an image. We would like to publish = later tonight: if anyone one wants an additional ACK before Sarah = publishes, please let us know NOW!

Regards
Lars

On 14 = May 2015, at 17:07, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tamas

On Thu, May 14, 2015 at 5:20 PM, = Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Looks fine to me
Unless there are further comments, I will encode this in the = blog in an hour or so

@Tamas: I will create an account for you and publish under = your name. You will then have to reset your password

Cheers
Lars
 

On 14 May 2015, at 14:32, = Lengyel, Tamas <tlengyel@novetta.com> = wrote:

=EF=BB=BFThis = is a guest blog post by Tamas K Lengyel, a long-time open source = enthusiast and Xen contributor. Tamas works as Senior Security = Researcher at Novetta, while finishing his PhD on the topic of malware = analysis and virtualization security at the University of Connecticut.
 
-------------
Hardening = Xen against VENOM-style attacks
 
 
The recent = disclosure of the VENOM[1] bug affecting major open-source hypervisors, = such as KVM and Xen, has been circulating in the tech news as of = 5/13/15, causing many to reevaluate their risks when using cloud = infrastructures. That is a very good thing indeed. Virtualization and = the cloud have been erroneously considered by many to be a silver bullet = against intrusions and malware in general. The fact is that the cloud is = anything but a safe place. There are inherent risks in the cloud, thus = it is very important to put those risks in context.
 
 
Hypervisors, = same as any other complex software systems, are prone to bugs and = errors. VENOM in that sense is just another one in the long list of = vulnerabilities that have been popping up against hypervisors[2]. While = VENOM is indeed a serious bug and can result in a VM escape, which in = turn can compromise all VMs on the host, it doesn=E2=80=99t have to be. = In fact, VENOM-style attacks have been known for a long time. And there = are easy-to-deploy counter-measures to mitigate the risk of such = exploits, natively available in both Xen and KVM (see RedHat=E2=80=99s = blog post on the same topic[3]).
 
 
What is the = root cause of VENOM? Emulation.
 
 
While modern = systems come with a plethora of virtualization extensions, many = components are still being emulated. The biggest component of that are = usually devices. Devices such as your network card, graphics card and = your hard drive. While Linux comes with paravirtual = (virtualization-aware) drivers to create such devices, emulation is = often the only solution to run operating systems that do not have such = kernel drivers. This has been traditionally the case with Windows[4]. = This emulation layer has been implemented in QEMU, which has caused = VENOM and a handful of other VM-escape bugs in recent years. However, = QEMU is not the only place where emulation is used within Xen. For a = variety of interrupts and timers, such as RTC, PIT, HPET, PMTimer, PIC, = IOAPIC and LAPIC, there is a baked-in emulator in Xen itself for = performance and scalability reasons[5]. As with QEMU, this emulator has = been just as exploitable[6]. This is simply because to program emulating = devices and services properly is really complex and error-prone. 
 
 
This fact, that = emulation is complex and error-prone, has been known for a long time. = Back in 2011, the Blackhat talk on Virtunoid[7] demonstrated such a VM = escape attack against KVM, through QEMU. The author of Virtunoid even = cautioned there will be many other bugs of that nature found by = researchers. Fast-forward 4 years and we now have VENOM.
 
 
The good news = is there is an easy mitigation available for all present and future QEMU = bugs, also mentioned in the original Xen Security Advisory[8]. It is = called stubdomains[9]. Stubdomains can nip the whole class of = vulnerabilities exposed by QEMU in the bud by moving QEMU into a = deprivileged domain of its own. Instead of having QEMU run as root in = dom0, a stubdomain has access only to the VM it is providing emulation = for. Thus, an escape through QEMU will only land an attacker in a = stubdomain, without access to critical resources. Furthermore, QEMU in a = stubdomain runs on MiniOS, thus an attacker would only have a very = limited environment to run code in (as in return-to-libc/ROP-style), = having exactly the same level of privilege as in the domain where the = attack started. Nothing is to be gained for a lot of work, effectively = making the system as secure as it would be if only PV drivers were used.
 
 
One would think = it is a complex process to take advantage of this protection, but in = fact, it is very simple. Add the following line to your Xen domain = configuration and you gain immediate protection against VENOM, and the = whole class of vulnerabilities brought to you by QEMU:

device_model_stubdomain_override =3D = 1 
 
However, as with most security = systems, it comes at a cost. Running stubdomains requires a bit of extra = memory as compared to the plain QEMU process in dom0. This in turn can = limit the number of VMs a cloud provider may be able to sell, thus there = is limited incentive on their end to enable this feature by default. = Further complicating the picture is the fact that this protection works = best if all VMs on the server run with stubdomains. Otherwise you may = end up protecting your neighbors against an escape attack from your = domain, while not being protected from an escape attack from theirs. It = is thus no surprise if some users would not want to pay for this extra = protection, even if it was available. However, for private clouds and = exclusive servers there is no reason why it shouldn=E2=80=99t be your = default setting. 
________________
[1] http://venom.crowdstrike.com/
[2] http://xenbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitte= n/.
[4] Citrix recently open-sourced its Windows PV drivers = so it is no longer the case: http://www.xenproject.org/downloads/windows-pv-drivers.html=
[5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtu= noid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com
_______________________________________________
Publicity = mailing list
Publicity@lists.xenproject.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity<= /a>




--
3D"www.novetta.com"
Tamas K = Lengyel
Senior = Security Researcher

7921 Jones Branch = Drive
McLean VA = 22102
Email =  tlengyel@novetta.com


= --Apple-Mail=_98A13FBE-548E-4F1F-87F4-F795FB7BC0A6-- --===============1963944387044006362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============1963944387044006362==-- From publicity-bounces@lists.xenproject.org Fri May 15 09:52:06 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 15 May 2015 09:52:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCHl-0004bd-Cu; Fri, 15 May 2015 09:52:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCHk-0004bN-3R for publicity@lists.xenproject.org; Fri, 15 May 2015 09:52:04 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id C6/99-02819-3C1C5555; Fri, 15 May 2015 09:52:03 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1431683520!10788054!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13325 invoked from network); 15 May 2015 09:52:00 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 15 May 2015 09:52:00 -0000 Received: by wgbhc8 with SMTP id hc8so73256570wgb.3 for ; Fri, 15 May 2015 02:52:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OOBzUoEDPsapzMzYw+7ElQszlQRsLS/dTSwZxJzz1LI=; b=bugz7Rw+fCEbxkH3hEj8aJQe4Nku0PBAj1WGbgEPrjHetIKVuXaIKPSBaxKAcypgZg ZYLvmJ5t5qUOxOOGtRrrLxgsBVjeRTKfwLCwPxtSqaxRSvFnLU0lVkyCAVfmHRkAi5FZ 2aNrovfwYFDFeFDitda1uOHInkSjTAZXAuPi44qkrho91DXKb+UyMzjXrtZwD67mtNLn dhgSLJqD4tRsxQefYThMlq9/jM/WzBNjJv5Jj6hpJKV9gyfuWKxK9rDCcOV3zxcS4OSn bCQ2To9NE1i7onE4ci92y60Ej/ijo34UiZKvfg4CTygxL5v3/GF7lRudJijVJQz7Ngcw NGJg== X-Gm-Message-State: ALoCoQkp7lxo748yphjrQBLMH57fpGquNmgxqiUGF0NElxjeS5JaZ3alixbHh4m4Jy4xYJlOBDFS MIME-Version: 1.0 X-Received: by 10.180.96.138 with SMTP id ds10mr5857761wib.95.1431683520141; Fri, 15 May 2015 02:52:00 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Fri, 15 May 2015 02:52:00 -0700 (PDT) In-Reply-To: References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> Date: Fri, 15 May 2015 11:52:00 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6803810326261842800==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6803810326261842800== Content-Type: multipart/alternative; boundary=f46d0442847aa6377205161bcb35 --f46d0442847aa6377205161bcb35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lars, it looks good to me! ;) Thanks, Tamas On Fri, May 15, 2015 at 10:39 AM, Lars Kurth wrote: > Tamas, > Sarah was making some minor changes. Please go to > https://blog.xenproject.org/?p=3D10701&preview=3Dtrue and log in via tlen= gyel > and let us know whether we are ready to publish. We probably want to do > this around noon UK time > Lars > > On 14 May 2015, at 17:45, Lars Kurth wrote: > > Hi all, > > the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtru= e > I made some minor mods: > * Inlined links > * Changed link [2] to a list of vulnerabilities covering different > hypervisor technologies > > Sarah may go and make some minor edits. She may also add an image. We > would like to publish later tonight: if anyone one wants an additional AC= K > before Sarah publishes, please let us know NOW! > > Regards > Lars > > On 14 May 2015, at 17:07, Lengyel, Tamas wrote: > > Hi Lars, > sounds good, thanks! > > Tamas > > On Thu, May 14, 2015 at 5:20 PM, Lars Kurth > wrote: > >> Looks fine to me >> Unless there are further comments, I will encode this in the blog in an >> hour or so >> >> @Tamas: I will create an account for you and publish under your name. Yo= u >> will then have to reset your password >> >> Cheers >> Lars >> >> >> On 14 May 2015, at 14:32, Lengyel, Tamas wrote: >> >> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open = source >> enthusiast and Xen contributor. Tamas works as Senior Security Researche= r >> at Novetta, while finishing his PhD on the topic of malware analysis and >> virtualization security at the University of Connecticut. >> >> ------------- >> Hardening Xen against VENOM-style attacks >> >> >> The recent disclosure of the VENOM[1] bug affecting major open-source >> hypervisors, such as KVM and Xen, has been circulating in the tech news = as >> of 5/13/15, causing many to reevaluate their risks when using cloud >> infrastructures. That is a very good thing indeed. Virtualization and th= e >> cloud have been erroneously considered by many to be a silver bullet >> against intrusions and malware in general. The fact is that the cloud is >> anything but a safe place. There are inherent risks in the cloud, thus i= t >> is very important to put those risks in context. >> >> >> Hypervisors, same as any other complex software systems, are prone to >> bugs and errors. VENOM in that sense is just another one in the long lis= t >> of vulnerabilities that have been popping up against hypervisors[2]. Whi= le >> VENOM is indeed a serious bug and can result in a VM escape, which in tu= rn >> can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fa= ct, >> VENOM-style attacks have been known for a long time. And there are >> easy-to-deploy counter-measures to mitigate the risk of such exploits, >> natively available in both Xen and KVM (see RedHat=E2=80=99s blog post o= n the same >> topic[3]). >> >> >> What is the root cause of VENOM? Emulation. >> >> >> While modern systems come with a plethora of virtualization extensions, >> many components are still being emulated. The biggest component of that = are >> usually devices. Devices such as your network card, graphics card and yo= ur >> hard drive. While Linux comes with paravirtual (virtualization-aware) >> drivers to create such devices, emulation is often the only solution to = run >> operating systems that do not have such kernel drivers. This has been >> traditionally the case with Windows[4]. This emulation layer has been >> implemented in QEMU, which has caused VENOM and a handful of other >> VM-escape bugs in recent years. However, QEMU is not the only place wher= e >> emulation is used within Xen. For a variety of interrupts and timers, su= ch >> as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in >> emulator in Xen itself for performance and scalability reasons[5]. As wi= th >> QEMU, this emulator has been just as exploitable[6]. This is simply beca= use >> to program emulating devices and services properly is really complex and >> error-prone. >> >> >> This fact, that emulation is complex and error-prone, has been known for >> a long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrate= d >> such a VM escape attack against KVM, through QEMU. The author of Virtuno= id >> even cautioned there will be many other bugs of that nature found by >> researchers. Fast-forward 4 years and we now have VENOM. >> >> >> The good news is there is an easy mitigation available for all present >> and future QEMU bugs, also mentioned in the original Xen Security >> Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole >> class of vulnerabilities exposed by QEMU in the bud by moving QEMU into = a >> deprivileged domain of its own. Instead of having QEMU run as root in do= m0, >> a stubdomain has access only to the VM it is providing emulation for. Th= us, >> an escape through QEMU will only land an attacker in a stubdomain, witho= ut >> access to critical resources. Furthermore, QEMU in a stubdomain runs on >> MiniOS, thus an attacker would only have a very limited environment to r= un >> code in (as in return-to-libc/ROP-style), having exactly the same level = of >> privilege as in the domain where the attack started. Nothing is to be >> gained for a lot of work, effectively making the system as secure as it >> would be if only PV drivers were used. >> >> >> One would think it is a complex process to take advantage of this >> protection, but in fact, it is very simple. Add the following line to yo= ur >> Xen domain configuration and you gain immediate protection against VENOM= , >> and the whole class of vulnerabilities brought to you by QEMU: >> >> device_model_stubdomain_override =3D 1 >> >> However, as with most security systems, it comes at a cost. Running >> stubdomains requires a bit of extra memory as compared to the plain QEMU >> process in dom0. This in turn can limit the number of VMs a cloud provid= er >> may be able to sell, thus there is limited incentive on their end to ena= ble >> this feature by default. Further complicating the picture is the fact th= at >> this protection works best if all VMs on the server run with stubdomains= . >> Otherwise you may end up protecting your neighbors against an escape att= ack >> from your domain, while not being protected from an escape attack from >> theirs. It is thus no surprise if some users would not want to pay for t= his >> extra protection, even if it was available. However, for private clouds = and >> exclusive servers there is no reason why it shouldn=E2=80=99t be your de= fault >> setting. >> ________________ >> [1] http://venom.crowdstrike.com/ >> [2] http://xenbits.xen.org/xsa/ >> [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. >> [4] Citrix recently open-sourced its Windows PV drivers so it is no >> longer the case: >> http://www.xenproject.org/downloads/windows-pv-drivers.html >> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 >> [6] http://xenbits.xen.org/xsa/advisory-105.html >> [7] >> http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.p= df >> [8] http://xenbits.xen.org/xsa/advisory-133.html >> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains >> >> -- >> [image: www.novetta.com] >> Tamas K Lengyel >> Senior Security Researcher >> >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com >> _______________________________________________ >> Publicity mailing list >> Publicity@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity >> >> >> > > > -- > [image: www.novetta.com] > Tamas K Lengyel > Senior Security Researcher > > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com > > > > --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --f46d0442847aa6377205161bcb35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lars,
it looks good to me! ;)
Thanks,
Tamas

=
On Fri, May 15, 2015 at 10:39 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Tamas,
Sarah was maki= ng some minor changes. Please go to=C2=A0https://blog.xenproje= ct.org/?p=3D10701&preview=3Dtrue=C2=A0and log in via tlengyel and l= et us know whether we are ready to publish. We probably want to do this aro= und noon UK time
L= ars

On 14 May 2015, at 17:45, Lars Kurth <lars.kurth.xen@gmail.com>= ; wrote:

Hi all,

=
I made some minor mods:
* Inlined links
* Changed link [2] to a list of vulnerabili= ties covering different hypervisor technologies

Sa= rah may go and make some minor edits. She may also add an image. We would l= ike to publish later tonight: if anyone one wants an additional ACK before = Sarah publishes, please let us know NOW!

Regards
Lars

On 14 May 2= 015, at 17:07, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tama= s

On Thu= , May 14, 2015 at 5:20 PM, Lars Kurth <lars.kurth.xen@gmail.com= > wrote:
Looks fine to me
Unless there are further comments, I wil= l encode this in the blog in an hour or so

@Tamas:= I will create an account for you and publish under your name. You will the= n have to reset your password

Cheers
Lar= s
=C2=A0

<= div>On 14 May 2015, at 14:32, Lengyel, Tamas <tlengyel@novetta.com> wrote:
=EF=BB=BFThis is a guest blog= post by Tamas K Lengyel, a long-time open source enthusiast and Xen contri= butor. Tamas works as Senior Security Researcher at Novetta, while finishin= g his PhD on the topic of malware analysis and virtualization security at t= he University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://= venom.crowdstrike.com/
[2] http://xe= nbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/ven= om-dont-get-bitten/.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv= -drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/34= 7492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/El= hage/BH_US_11_Elhage_Virtunoid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researc= her

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">
_______________________________________________
Publicity mailing listPubli= city@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/publicity

=



--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researcher

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">





--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--f46d0442847aa6377205161bcb35-- --===============6803810326261842800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6803810326261842800==-- From publicity-bounces@lists.xenproject.org Fri May 15 09:52:06 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 15 May 2015 09:52:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCHl-0004bd-Cu; Fri, 15 May 2015 09:52:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCHk-0004bN-3R for publicity@lists.xenproject.org; Fri, 15 May 2015 09:52:04 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id C6/99-02819-3C1C5555; Fri, 15 May 2015 09:52:03 +0000 X-Env-Sender: tlengyel@novetta.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1431683520!10788054!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13325 invoked from network); 15 May 2015 09:52:00 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 15 May 2015 09:52:00 -0000 Received: by wgbhc8 with SMTP id hc8so73256570wgb.3 for ; Fri, 15 May 2015 02:52:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OOBzUoEDPsapzMzYw+7ElQszlQRsLS/dTSwZxJzz1LI=; b=bugz7Rw+fCEbxkH3hEj8aJQe4Nku0PBAj1WGbgEPrjHetIKVuXaIKPSBaxKAcypgZg ZYLvmJ5t5qUOxOOGtRrrLxgsBVjeRTKfwLCwPxtSqaxRSvFnLU0lVkyCAVfmHRkAi5FZ 2aNrovfwYFDFeFDitda1uOHInkSjTAZXAuPi44qkrho91DXKb+UyMzjXrtZwD67mtNLn dhgSLJqD4tRsxQefYThMlq9/jM/WzBNjJv5Jj6hpJKV9gyfuWKxK9rDCcOV3zxcS4OSn bCQ2To9NE1i7onE4ci92y60Ej/ijo34UiZKvfg4CTygxL5v3/GF7lRudJijVJQz7Ngcw NGJg== X-Gm-Message-State: ALoCoQkp7lxo748yphjrQBLMH57fpGquNmgxqiUGF0NElxjeS5JaZ3alixbHh4m4Jy4xYJlOBDFS MIME-Version: 1.0 X-Received: by 10.180.96.138 with SMTP id ds10mr5857761wib.95.1431683520141; Fri, 15 May 2015 02:52:00 -0700 (PDT) Received: by 10.194.124.43 with HTTP; Fri, 15 May 2015 02:52:00 -0700 (PDT) In-Reply-To: References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> Date: Fri, 15 May 2015 11:52:00 +0200 Message-ID: From: "Lengyel, Tamas" To: Lars Kurth Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6803810326261842800==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6803810326261842800== Content-Type: multipart/alternative; boundary=f46d0442847aa6377205161bcb35 --f46d0442847aa6377205161bcb35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lars, it looks good to me! ;) Thanks, Tamas On Fri, May 15, 2015 at 10:39 AM, Lars Kurth wrote: > Tamas, > Sarah was making some minor changes. Please go to > https://blog.xenproject.org/?p=3D10701&preview=3Dtrue and log in via tlen= gyel > and let us know whether we are ready to publish. We probably want to do > this around noon UK time > Lars > > On 14 May 2015, at 17:45, Lars Kurth wrote: > > Hi all, > > the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtru= e > I made some minor mods: > * Inlined links > * Changed link [2] to a list of vulnerabilities covering different > hypervisor technologies > > Sarah may go and make some minor edits. She may also add an image. We > would like to publish later tonight: if anyone one wants an additional AC= K > before Sarah publishes, please let us know NOW! > > Regards > Lars > > On 14 May 2015, at 17:07, Lengyel, Tamas wrote: > > Hi Lars, > sounds good, thanks! > > Tamas > > On Thu, May 14, 2015 at 5:20 PM, Lars Kurth > wrote: > >> Looks fine to me >> Unless there are further comments, I will encode this in the blog in an >> hour or so >> >> @Tamas: I will create an account for you and publish under your name. Yo= u >> will then have to reset your password >> >> Cheers >> Lars >> >> >> On 14 May 2015, at 14:32, Lengyel, Tamas wrote: >> >> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open = source >> enthusiast and Xen contributor. Tamas works as Senior Security Researche= r >> at Novetta, while finishing his PhD on the topic of malware analysis and >> virtualization security at the University of Connecticut. >> >> ------------- >> Hardening Xen against VENOM-style attacks >> >> >> The recent disclosure of the VENOM[1] bug affecting major open-source >> hypervisors, such as KVM and Xen, has been circulating in the tech news = as >> of 5/13/15, causing many to reevaluate their risks when using cloud >> infrastructures. That is a very good thing indeed. Virtualization and th= e >> cloud have been erroneously considered by many to be a silver bullet >> against intrusions and malware in general. The fact is that the cloud is >> anything but a safe place. There are inherent risks in the cloud, thus i= t >> is very important to put those risks in context. >> >> >> Hypervisors, same as any other complex software systems, are prone to >> bugs and errors. VENOM in that sense is just another one in the long lis= t >> of vulnerabilities that have been popping up against hypervisors[2]. Whi= le >> VENOM is indeed a serious bug and can result in a VM escape, which in tu= rn >> can compromise all VMs on the host, it doesn=E2=80=99t have to be. In fa= ct, >> VENOM-style attacks have been known for a long time. And there are >> easy-to-deploy counter-measures to mitigate the risk of such exploits, >> natively available in both Xen and KVM (see RedHat=E2=80=99s blog post o= n the same >> topic[3]). >> >> >> What is the root cause of VENOM? Emulation. >> >> >> While modern systems come with a plethora of virtualization extensions, >> many components are still being emulated. The biggest component of that = are >> usually devices. Devices such as your network card, graphics card and yo= ur >> hard drive. While Linux comes with paravirtual (virtualization-aware) >> drivers to create such devices, emulation is often the only solution to = run >> operating systems that do not have such kernel drivers. This has been >> traditionally the case with Windows[4]. This emulation layer has been >> implemented in QEMU, which has caused VENOM and a handful of other >> VM-escape bugs in recent years. However, QEMU is not the only place wher= e >> emulation is used within Xen. For a variety of interrupts and timers, su= ch >> as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in >> emulator in Xen itself for performance and scalability reasons[5]. As wi= th >> QEMU, this emulator has been just as exploitable[6]. This is simply beca= use >> to program emulating devices and services properly is really complex and >> error-prone. >> >> >> This fact, that emulation is complex and error-prone, has been known for >> a long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrate= d >> such a VM escape attack against KVM, through QEMU. The author of Virtuno= id >> even cautioned there will be many other bugs of that nature found by >> researchers. Fast-forward 4 years and we now have VENOM. >> >> >> The good news is there is an easy mitigation available for all present >> and future QEMU bugs, also mentioned in the original Xen Security >> Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole >> class of vulnerabilities exposed by QEMU in the bud by moving QEMU into = a >> deprivileged domain of its own. Instead of having QEMU run as root in do= m0, >> a stubdomain has access only to the VM it is providing emulation for. Th= us, >> an escape through QEMU will only land an attacker in a stubdomain, witho= ut >> access to critical resources. Furthermore, QEMU in a stubdomain runs on >> MiniOS, thus an attacker would only have a very limited environment to r= un >> code in (as in return-to-libc/ROP-style), having exactly the same level = of >> privilege as in the domain where the attack started. Nothing is to be >> gained for a lot of work, effectively making the system as secure as it >> would be if only PV drivers were used. >> >> >> One would think it is a complex process to take advantage of this >> protection, but in fact, it is very simple. Add the following line to yo= ur >> Xen domain configuration and you gain immediate protection against VENOM= , >> and the whole class of vulnerabilities brought to you by QEMU: >> >> device_model_stubdomain_override =3D 1 >> >> However, as with most security systems, it comes at a cost. Running >> stubdomains requires a bit of extra memory as compared to the plain QEMU >> process in dom0. This in turn can limit the number of VMs a cloud provid= er >> may be able to sell, thus there is limited incentive on their end to ena= ble >> this feature by default. Further complicating the picture is the fact th= at >> this protection works best if all VMs on the server run with stubdomains= . >> Otherwise you may end up protecting your neighbors against an escape att= ack >> from your domain, while not being protected from an escape attack from >> theirs. It is thus no surprise if some users would not want to pay for t= his >> extra protection, even if it was available. However, for private clouds = and >> exclusive servers there is no reason why it shouldn=E2=80=99t be your de= fault >> setting. >> ________________ >> [1] http://venom.crowdstrike.com/ >> [2] http://xenbits.xen.org/xsa/ >> [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. >> [4] Citrix recently open-sourced its Windows PV drivers so it is no >> longer the case: >> http://www.xenproject.org/downloads/windows-pv-drivers.html >> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 >> [6] http://xenbits.xen.org/xsa/advisory-105.html >> [7] >> http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.p= df >> [8] http://xenbits.xen.org/xsa/advisory-133.html >> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains >> >> -- >> [image: www.novetta.com] >> Tamas K Lengyel >> Senior Security Researcher >> >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com >> _______________________________________________ >> Publicity mailing list >> Publicity@lists.xenproject.org >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity >> >> >> > > > -- > [image: www.novetta.com] > Tamas K Lengyel > Senior Security Researcher > > 7921 Jones Branch Drive > McLean VA 22102 > Email tlengyel@novetta.com > > > > --=20 [image: www.novetta.com] Tamas K Lengyel Senior Security Researcher 7921 Jones Branch Drive McLean VA 22102 Email tlengyel@novetta.com --f46d0442847aa6377205161bcb35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lars,
it looks good to me! ;)
Thanks,
Tamas

=
On Fri, May 15, 2015 at 10:39 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Tamas,
Sarah was maki= ng some minor changes. Please go to=C2=A0https://blog.xenproje= ct.org/?p=3D10701&preview=3Dtrue=C2=A0and log in via tlengyel and l= et us know whether we are ready to publish. We probably want to do this aro= und noon UK time
L= ars

On 14 May 2015, at 17:45, Lars Kurth <lars.kurth.xen@gmail.com>= ; wrote:

Hi all,

=
I made some minor mods:
* Inlined links
* Changed link [2] to a list of vulnerabili= ties covering different hypervisor technologies

Sa= rah may go and make some minor edits. She may also add an image. We would l= ike to publish later tonight: if anyone one wants an additional ACK before = Sarah publishes, please let us know NOW!

Regards
Lars

On 14 May 2= 015, at 17:07, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tama= s

On Thu= , May 14, 2015 at 5:20 PM, Lars Kurth <lars.kurth.xen@gmail.com= > wrote:
Looks fine to me
Unless there are further comments, I wil= l encode this in the blog in an hour or so

@Tamas:= I will create an account for you and publish under your name. You will the= n have to reset your password

Cheers
Lar= s
=C2=A0

<= div>On 14 May 2015, at 14:32, Lengyel, Tamas <tlengyel@novetta.com> wrote:
=EF=BB=BFThis is a guest blog= post by Tamas K Lengyel, a long-time open source enthusiast and Xen contri= butor. Tamas works as Senior Security Researcher at Novetta, while finishin= g his PhD on the topic of malware analysis and virtualization security at t= he University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://= venom.crowdstrike.com/
[2] http://xe= nbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/ven= om-dont-get-bitten/.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv= -drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/34= 7492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/El= hage/BH_US_11_Elhage_Virtunoid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researc= her

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">
_______________________________________________
Publicity mailing listPubli= city@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/publicity

=



--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researcher

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">





--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com

--f46d0442847aa6377205161bcb35-- --===============6803810326261842800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6803810326261842800==-- From publicity-bounces@lists.xenproject.org Fri May 15 10:35:25 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 15 May 2015 10:35:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCxf-00085K-QI; Fri, 15 May 2015 10:35:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCxd-00085E-G1 for publicity@lists.xenproject.org; Fri, 15 May 2015 10:35:21 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 2E/1D-02795-8EBC5555; Fri, 15 May 2015 10:35:20 +0000 X-Env-Sender: sconway@linuxfoundation.org X-Msg-Ref: server-5.tower-27.messagelabs.com!1431686116!13159346!1 X-Originating-IP: [209.85.223.176] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1628 invoked from network); 15 May 2015 10:35:17 -0000 Received: from mail-ie0-f176.google.com (HELO mail-ie0-f176.google.com) (209.85.223.176) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 May 2015 10:35:17 -0000 Received: by iesa3 with SMTP id a3so16845573ies.2 for ; Fri, 15 May 2015 03:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qFGT7URIjk34WwGNDGE8uIfLb8R8op5gchAvST2RcAE=; b=ZgE8kk4P54Jkmkm0zIlQ6l5HGwA//FWa9HTQ+RFgH60Joif0cW9Qy5Pk9g5bD3deQS RlTG0/GmVp/RTBck8DhFB5ZeaeBW3fNL1hFqBiAxkU8pCSs/d/cpMHF407aKWY5S/Kw3 t5oodXjh+5DnkJdP4RWPrz2xBUgP1G6PAKcXQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qFGT7URIjk34WwGNDGE8uIfLb8R8op5gchAvST2RcAE=; b=jj0AnV/9xWXAmtm3fIa4Di7YGSEHv46cniBxWNE8u/k4bWh2IY39V9/zD7jnaNQfkY PtQSInp5zZjSJfqxYz0zy7HsiCPNexbsNIbeiH9DIAZ8gcWtfr2EIIiqjmSiAgqQiN1H 1ljJMyOX1GEr/PeqRtzIG+1n1Q5yjcF6J5lOufTK1BavXclzfx5HdstI0bMANnWeHRkS OVOlgIA1lDlsFXVCYoqc8Sk/Z6O345U1JD/JoPR79JaD6gY2IiCUbivQKNx5QRP4mBjL LyVmB9hlr6t86hHZGntZo9r5QQZY9Z+yhnPJRp+U3u8xQWGKChcB0NTEWp3w1kxT/ttn BAMA== X-Gm-Message-State: ALoCoQnFVZ32AfhosAtUSCSJVhQrpaAyfRq9uyGIqrIkYjJxeulXSe8EDm4bWPJCPq/33iVUpFye MIME-Version: 1.0 X-Received: by 10.107.29.148 with SMTP id d142mr12270657iod.9.1431686116447; Fri, 15 May 2015 03:35:16 -0700 (PDT) Received: by 10.36.0.213 with HTTP; Fri, 15 May 2015 03:35:16 -0700 (PDT) In-Reply-To: References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> Date: Fri, 15 May 2015 06:35:16 -0400 Message-ID: From: Sarah Conway To: "Lengyel, Tamas" Cc: Lars Kurth , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2538894772734301765==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============2538894772734301765== Content-Type: multipart/alternative; boundary=001a114089c466bb8f05161c6697 --001a114089c466bb8f05161c6697 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great. I will post around 9 a.m. ET this morning. Thanks, On Fri, May 15, 2015 at 5:52 AM, Lengyel, Tamas wrote: > Hi Lars, > it looks good to me! ;) > > Thanks, > Tamas > > On Fri, May 15, 2015 at 10:39 AM, Lars Kurth > wrote: > >> Tamas, >> Sarah was making some minor changes. Please go to >> https://blog.xenproject.org/?p=3D10701&preview=3Dtrue and log in via >> tlengyel and let us know whether we are ready to publish. We probably wa= nt >> to do this around noon UK time >> Lars >> >> On 14 May 2015, at 17:45, Lars Kurth wrote: >> >> Hi all, >> >> the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtr= ue >> I made some minor mods: >> * Inlined links >> * Changed link [2] to a list of vulnerabilities covering different >> hypervisor technologies >> >> Sarah may go and make some minor edits. She may also add an image. We >> would like to publish later tonight: if anyone one wants an additional A= CK >> before Sarah publishes, please let us know NOW! >> >> Regards >> Lars >> >> On 14 May 2015, at 17:07, Lengyel, Tamas wrote: >> >> Hi Lars, >> sounds good, thanks! >> >> Tamas >> >> On Thu, May 14, 2015 at 5:20 PM, Lars Kurth >> wrote: >> >>> Looks fine to me >>> Unless there are further comments, I will encode this in the blog in an >>> hour or so >>> >>> @Tamas: I will create an account for you and publish under your name. >>> You will then have to reset your password >>> >>> Cheers >>> Lars >>> >>> >>> On 14 May 2015, at 14:32, Lengyel, Tamas wrote: >>> >>> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open= source >>> enthusiast and Xen contributor. Tamas works as Senior Security Research= er >>> at Novetta, while finishing his PhD on the topic of malware analysis an= d >>> virtualization security at the University of Connecticut. >>> >>> ------------- >>> Hardening Xen against VENOM-style attacks >>> >>> >>> The recent disclosure of the VENOM[1] bug affecting major open-source >>> hypervisors, such as KVM and Xen, has been circulating in the tech news= as >>> of 5/13/15, causing many to reevaluate their risks when using cloud >>> infrastructures. That is a very good thing indeed. Virtualization and t= he >>> cloud have been erroneously considered by many to be a silver bullet >>> against intrusions and malware in general. The fact is that the cloud i= s >>> anything but a safe place. There are inherent risks in the cloud, thus = it >>> is very important to put those risks in context. >>> >>> >>> Hypervisors, same as any other complex software systems, are prone to >>> bugs and errors. VENOM in that sense is just another one in the long li= st >>> of vulnerabilities that have been popping up against hypervisors[2]. Wh= ile >>> VENOM is indeed a serious bug and can result in a VM escape, which in t= urn >>> can compromise all VMs on the host, it doesn=E2=80=99t have to be. In f= act, >>> VENOM-style attacks have been known for a long time. And there are >>> easy-to-deploy counter-measures to mitigate the risk of such exploits, >>> natively available in both Xen and KVM (see RedHat=E2=80=99s blog post = on the same >>> topic[3]). >>> >>> >>> What is the root cause of VENOM? Emulation. >>> >>> >>> While modern systems come with a plethora of virtualization extensions, >>> many components are still being emulated. The biggest component of that= are >>> usually devices. Devices such as your network card, graphics card and y= our >>> hard drive. While Linux comes with paravirtual (virtualization-aware) >>> drivers to create such devices, emulation is often the only solution to= run >>> operating systems that do not have such kernel drivers. This has been >>> traditionally the case with Windows[4]. This emulation layer has been >>> implemented in QEMU, which has caused VENOM and a handful of other >>> VM-escape bugs in recent years. However, QEMU is not the only place whe= re >>> emulation is used within Xen. For a variety of interrupts and timers, s= uch >>> as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in >>> emulator in Xen itself for performance and scalability reasons[5]. As w= ith >>> QEMU, this emulator has been just as exploitable[6]. This is simply bec= ause >>> to program emulating devices and services properly is really complex an= d >>> error-prone. >>> >>> >>> This fact, that emulation is complex and error-prone, has been known fo= r >>> a long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrat= ed >>> such a VM escape attack against KVM, through QEMU. The author of Virtun= oid >>> even cautioned there will be many other bugs of that nature found by >>> researchers. Fast-forward 4 years and we now have VENOM. >>> >>> >>> The good news is there is an easy mitigation available for all present >>> and future QEMU bugs, also mentioned in the original Xen Security >>> Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole >>> class of vulnerabilities exposed by QEMU in the bud by moving QEMU into= a >>> deprivileged domain of its own. Instead of having QEMU run as root in d= om0, >>> a stubdomain has access only to the VM it is providing emulation for. T= hus, >>> an escape through QEMU will only land an attacker in a stubdomain, with= out >>> access to critical resources. Furthermore, QEMU in a stubdomain runs on >>> MiniOS, thus an attacker would only have a very limited environment to = run >>> code in (as in return-to-libc/ROP-style), having exactly the same level= of >>> privilege as in the domain where the attack started. Nothing is to be >>> gained for a lot of work, effectively making the system as secure as it >>> would be if only PV drivers were used. >>> >>> >>> One would think it is a complex process to take advantage of this >>> protection, but in fact, it is very simple. Add the following line to y= our >>> Xen domain configuration and you gain immediate protection against VENO= M, >>> and the whole class of vulnerabilities brought to you by QEMU: >>> >>> device_model_stubdomain_override =3D 1 >>> >>> However, as with most security systems, it comes at a cost. Running >>> stubdomains requires a bit of extra memory as compared to the plain QEM= U >>> process in dom0. This in turn can limit the number of VMs a cloud provi= der >>> may be able to sell, thus there is limited incentive on their end to en= able >>> this feature by default. Further complicating the picture is the fact t= hat >>> this protection works best if all VMs on the server run with stubdomain= s. >>> Otherwise you may end up protecting your neighbors against an escape at= tack >>> from your domain, while not being protected from an escape attack from >>> theirs. It is thus no surprise if some users would not want to pay for = this >>> extra protection, even if it was available. However, for private clouds= and >>> exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault >>> setting. >>> ________________ >>> [1] http://venom.crowdstrike.com/ >>> [2] http://xenbits.xen.org/xsa/ >>> [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. >>> [4] Citrix recently open-sourced its Windows PV drivers so it is no >>> longer the case: >>> http://www.xenproject.org/downloads/windows-pv-drivers.html >>> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 >>> [6] http://xenbits.xen.org/xsa/advisory-105.html >>> [7] >>> http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.= pdf >>> [8] http://xenbits.xen.org/xsa/advisory-133.html >>> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains >>> >>> -- >>> [image: www.novetta.com] >>> Tamas K Lengyel >>> Senior Security Researcher >>> >>> 7921 Jones Branch Drive >>> McLean VA 22102 >>> Email tlengyel@novetta.com >>> _______________________________________________ >>> Publicity mailing list >>> Publicity@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity >>> >>> >>> >> >> >> -- >> [image: www.novetta.com] >> Tamas K Lengyel >> Senior Security Researcher >> >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com >> >> >> >> > > > -- > > [image: www.novetta.com] > > Tamas K Lengyel > > Senior Security Researcher > > 7921 Jones Branch Drive > > McLean VA 22102 > > Email tlengyel@novetta.com > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > --=20 Sarah Conway PR Manager The Linux Foundation sconway@linuxfoundation.org (978) 578-5300 Cell Skype: sarah.k.conway --001a114089c466bb8f05161c6697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great. I will post around 9 a.m. ET this morning.

=
Thanks,

On Fri, May 15, 2015 at 5:52 AM, Lengyel, Tamas <tlengyel@= novetta.com> wrote:
Hi Lars,
it looks good to me! ;)

<= /div>Thanks,
Tamas

On Fri, May 15,= 2015 at 10:39 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Tamas,
Sarah was making some minor changes. Please go to=C2=A0https://blog.xenproject.org/?p=3D10701&preview=3Dtrue= =C2=A0and log in via tlengyel and let us know whether we are ready to publi= sh. We probably want to do this around noon UK time
Lars

On 14 May 2015, at 17:45, Lars Kurth <lars.kurth.xen@gmail.com<= /a>> wrote:

Hi all,
I made some minor mods= :
* Inlined links
* Changed link [2] to a list of vulne= rabilities covering different hypervisor technologies

<= div>Sarah may go and make some minor edits. She may also add an image. We w= ould like to publish later tonight: if anyone one wants an additional ACK b= efore Sarah publishes, please let us know NOW!

Reg= ards
Lars

On 14= May 2015, at 17:07, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tamas

= On Thu, May 14, 2015 at 5:20 PM, Lars Kurth <lars.kurth.xen@gmail= .com> wrote:
Looks fine to me
Unless there are further comment= s, I will encode this in the blog in an hour or so

@Tamas: I will create an account for you and publish under your name. You = will then have to reset your password

Cheers
=
Lars
=C2=A0

On 14 May 2015, at 14:32, Lengyel, Tamas <tlengyel@novetta.com> wrote:=

=EF=BB=BFThis is a gu= est blog post by Tamas K Lengyel, a long-time open source enthusiast and Xe= n contributor. Tamas works as Senior Security Researcher at Novetta, while = finishing his PhD on the topic of malware analysis and virtualization secur= ity at the University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://= venom.crowdstrike.com/
[2] http://xe= nbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/ven= om-dont-get-bitten/.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv= -drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/34= 7492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/El= hage/BH_US_11_Elhage_Virtunoid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researc= her

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">
_______________________________________________
Publicity mailing listPubli= city@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/publicity

=



--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researcher

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">





--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com


_______________________________________________
Publicity mailing list
Publicity@lists.xenprojec= t.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publ= icity




--
Sarah Conway
PR = Manager
The Linux Foundation
sconway@linuxfoundation.org
(= 978) 578-5300 =C2=A0Cell
Skype: =C2=A0sarah.k.conway
<= /div>
--001a114089c466bb8f05161c6697-- --===============2538894772734301765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============2538894772734301765==-- From publicity-bounces@lists.xenproject.org Fri May 15 10:35:25 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 15 May 2015 10:35:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCxf-00085K-QI; Fri, 15 May 2015 10:35:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YtCxd-00085E-G1 for publicity@lists.xenproject.org; Fri, 15 May 2015 10:35:21 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 2E/1D-02795-8EBC5555; Fri, 15 May 2015 10:35:20 +0000 X-Env-Sender: sconway@linuxfoundation.org X-Msg-Ref: server-5.tower-27.messagelabs.com!1431686116!13159346!1 X-Originating-IP: [209.85.223.176] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1628 invoked from network); 15 May 2015 10:35:17 -0000 Received: from mail-ie0-f176.google.com (HELO mail-ie0-f176.google.com) (209.85.223.176) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 May 2015 10:35:17 -0000 Received: by iesa3 with SMTP id a3so16845573ies.2 for ; Fri, 15 May 2015 03:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qFGT7URIjk34WwGNDGE8uIfLb8R8op5gchAvST2RcAE=; b=ZgE8kk4P54Jkmkm0zIlQ6l5HGwA//FWa9HTQ+RFgH60Joif0cW9Qy5Pk9g5bD3deQS RlTG0/GmVp/RTBck8DhFB5ZeaeBW3fNL1hFqBiAxkU8pCSs/d/cpMHF407aKWY5S/Kw3 t5oodXjh+5DnkJdP4RWPrz2xBUgP1G6PAKcXQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qFGT7URIjk34WwGNDGE8uIfLb8R8op5gchAvST2RcAE=; b=jj0AnV/9xWXAmtm3fIa4Di7YGSEHv46cniBxWNE8u/k4bWh2IY39V9/zD7jnaNQfkY PtQSInp5zZjSJfqxYz0zy7HsiCPNexbsNIbeiH9DIAZ8gcWtfr2EIIiqjmSiAgqQiN1H 1ljJMyOX1GEr/PeqRtzIG+1n1Q5yjcF6J5lOufTK1BavXclzfx5HdstI0bMANnWeHRkS OVOlgIA1lDlsFXVCYoqc8Sk/Z6O345U1JD/JoPR79JaD6gY2IiCUbivQKNx5QRP4mBjL LyVmB9hlr6t86hHZGntZo9r5QQZY9Z+yhnPJRp+U3u8xQWGKChcB0NTEWp3w1kxT/ttn BAMA== X-Gm-Message-State: ALoCoQnFVZ32AfhosAtUSCSJVhQrpaAyfRq9uyGIqrIkYjJxeulXSe8EDm4bWPJCPq/33iVUpFye MIME-Version: 1.0 X-Received: by 10.107.29.148 with SMTP id d142mr12270657iod.9.1431686116447; Fri, 15 May 2015 03:35:16 -0700 (PDT) Received: by 10.36.0.213 with HTTP; Fri, 15 May 2015 03:35:16 -0700 (PDT) In-Reply-To: References: <590FF5F9-BB93-438A-94A7-67BB80181927@gmail.com> <696CE24D-9D0D-40A3-961D-3CD235B8D144@gmail.com> Date: Fri, 15 May 2015 06:35:16 -0400 Message-ID: From: Sarah Conway To: "Lengyel, Tamas" Cc: Lars Kurth , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Blog-post RFC v2: Hardening Xen against VENOM-style attacks X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2538894772734301765==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============2538894772734301765== Content-Type: multipart/alternative; boundary=001a114089c466bb8f05161c6697 --001a114089c466bb8f05161c6697 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great. I will post around 9 a.m. ET this morning. Thanks, On Fri, May 15, 2015 at 5:52 AM, Lengyel, Tamas wrote: > Hi Lars, > it looks good to me! ;) > > Thanks, > Tamas > > On Fri, May 15, 2015 at 10:39 AM, Lars Kurth > wrote: > >> Tamas, >> Sarah was making some minor changes. Please go to >> https://blog.xenproject.org/?p=3D10701&preview=3Dtrue and log in via >> tlengyel and let us know whether we are ready to publish. We probably wa= nt >> to do this around noon UK time >> Lars >> >> On 14 May 2015, at 17:45, Lars Kurth wrote: >> >> Hi all, >> >> the draft most is at https://blog.xenproject.org/?p=3D10701&preview=3Dtr= ue >> I made some minor mods: >> * Inlined links >> * Changed link [2] to a list of vulnerabilities covering different >> hypervisor technologies >> >> Sarah may go and make some minor edits. She may also add an image. We >> would like to publish later tonight: if anyone one wants an additional A= CK >> before Sarah publishes, please let us know NOW! >> >> Regards >> Lars >> >> On 14 May 2015, at 17:07, Lengyel, Tamas wrote: >> >> Hi Lars, >> sounds good, thanks! >> >> Tamas >> >> On Thu, May 14, 2015 at 5:20 PM, Lars Kurth >> wrote: >> >>> Looks fine to me >>> Unless there are further comments, I will encode this in the blog in an >>> hour or so >>> >>> @Tamas: I will create an account for you and publish under your name. >>> You will then have to reset your password >>> >>> Cheers >>> Lars >>> >>> >>> On 14 May 2015, at 14:32, Lengyel, Tamas wrote: >>> >>> =EF=BB=BFThis is a guest blog post by Tamas K Lengyel, a long-time open= source >>> enthusiast and Xen contributor. Tamas works as Senior Security Research= er >>> at Novetta, while finishing his PhD on the topic of malware analysis an= d >>> virtualization security at the University of Connecticut. >>> >>> ------------- >>> Hardening Xen against VENOM-style attacks >>> >>> >>> The recent disclosure of the VENOM[1] bug affecting major open-source >>> hypervisors, such as KVM and Xen, has been circulating in the tech news= as >>> of 5/13/15, causing many to reevaluate their risks when using cloud >>> infrastructures. That is a very good thing indeed. Virtualization and t= he >>> cloud have been erroneously considered by many to be a silver bullet >>> against intrusions and malware in general. The fact is that the cloud i= s >>> anything but a safe place. There are inherent risks in the cloud, thus = it >>> is very important to put those risks in context. >>> >>> >>> Hypervisors, same as any other complex software systems, are prone to >>> bugs and errors. VENOM in that sense is just another one in the long li= st >>> of vulnerabilities that have been popping up against hypervisors[2]. Wh= ile >>> VENOM is indeed a serious bug and can result in a VM escape, which in t= urn >>> can compromise all VMs on the host, it doesn=E2=80=99t have to be. In f= act, >>> VENOM-style attacks have been known for a long time. And there are >>> easy-to-deploy counter-measures to mitigate the risk of such exploits, >>> natively available in both Xen and KVM (see RedHat=E2=80=99s blog post = on the same >>> topic[3]). >>> >>> >>> What is the root cause of VENOM? Emulation. >>> >>> >>> While modern systems come with a plethora of virtualization extensions, >>> many components are still being emulated. The biggest component of that= are >>> usually devices. Devices such as your network card, graphics card and y= our >>> hard drive. While Linux comes with paravirtual (virtualization-aware) >>> drivers to create such devices, emulation is often the only solution to= run >>> operating systems that do not have such kernel drivers. This has been >>> traditionally the case with Windows[4]. This emulation layer has been >>> implemented in QEMU, which has caused VENOM and a handful of other >>> VM-escape bugs in recent years. However, QEMU is not the only place whe= re >>> emulation is used within Xen. For a variety of interrupts and timers, s= uch >>> as RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in >>> emulator in Xen itself for performance and scalability reasons[5]. As w= ith >>> QEMU, this emulator has been just as exploitable[6]. This is simply bec= ause >>> to program emulating devices and services properly is really complex an= d >>> error-prone. >>> >>> >>> This fact, that emulation is complex and error-prone, has been known fo= r >>> a long time. Back in 2011, the Blackhat talk on Virtunoid[7] demonstrat= ed >>> such a VM escape attack against KVM, through QEMU. The author of Virtun= oid >>> even cautioned there will be many other bugs of that nature found by >>> researchers. Fast-forward 4 years and we now have VENOM. >>> >>> >>> The good news is there is an easy mitigation available for all present >>> and future QEMU bugs, also mentioned in the original Xen Security >>> Advisory[8]. It is called stubdomains[9]. Stubdomains can nip the whole >>> class of vulnerabilities exposed by QEMU in the bud by moving QEMU into= a >>> deprivileged domain of its own. Instead of having QEMU run as root in d= om0, >>> a stubdomain has access only to the VM it is providing emulation for. T= hus, >>> an escape through QEMU will only land an attacker in a stubdomain, with= out >>> access to critical resources. Furthermore, QEMU in a stubdomain runs on >>> MiniOS, thus an attacker would only have a very limited environment to = run >>> code in (as in return-to-libc/ROP-style), having exactly the same level= of >>> privilege as in the domain where the attack started. Nothing is to be >>> gained for a lot of work, effectively making the system as secure as it >>> would be if only PV drivers were used. >>> >>> >>> One would think it is a complex process to take advantage of this >>> protection, but in fact, it is very simple. Add the following line to y= our >>> Xen domain configuration and you gain immediate protection against VENO= M, >>> and the whole class of vulnerabilities brought to you by QEMU: >>> >>> device_model_stubdomain_override =3D 1 >>> >>> However, as with most security systems, it comes at a cost. Running >>> stubdomains requires a bit of extra memory as compared to the plain QEM= U >>> process in dom0. This in turn can limit the number of VMs a cloud provi= der >>> may be able to sell, thus there is limited incentive on their end to en= able >>> this feature by default. Further complicating the picture is the fact t= hat >>> this protection works best if all VMs on the server run with stubdomain= s. >>> Otherwise you may end up protecting your neighbors against an escape at= tack >>> from your domain, while not being protected from an escape attack from >>> theirs. It is thus no surprise if some users would not want to pay for = this >>> extra protection, even if it was available. However, for private clouds= and >>> exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault >>> setting. >>> ________________ >>> [1] http://venom.crowdstrike.com/ >>> [2] http://xenbits.xen.org/xsa/ >>> [3] https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/. >>> [4] Citrix recently open-sourced its Windows PV drivers so it is no >>> longer the case: >>> http://www.xenproject.org/downloads/windows-pv-drivers.html >>> [5] http://www.gossamer-threads.com/lists/xen/devel/347492#347492 >>> [6] http://xenbits.xen.org/xsa/advisory-105.html >>> [7] >>> http://media.blackhat.com/bh-us-11/Elhage/BH_US_11_Elhage_Virtunoid_WP.= pdf >>> [8] http://xenbits.xen.org/xsa/advisory-133.html >>> [9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains >>> >>> -- >>> [image: www.novetta.com] >>> Tamas K Lengyel >>> Senior Security Researcher >>> >>> 7921 Jones Branch Drive >>> McLean VA 22102 >>> Email tlengyel@novetta.com >>> _______________________________________________ >>> Publicity mailing list >>> Publicity@lists.xenproject.org >>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity >>> >>> >>> >> >> >> -- >> [image: www.novetta.com] >> Tamas K Lengyel >> Senior Security Researcher >> >> 7921 Jones Branch Drive >> McLean VA 22102 >> Email tlengyel@novetta.com >> >> >> >> > > > -- > > [image: www.novetta.com] > > Tamas K Lengyel > > Senior Security Researcher > > 7921 Jones Branch Drive > > McLean VA 22102 > > Email tlengyel@novetta.com > > _______________________________________________ > Publicity mailing list > Publicity@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity > > --=20 Sarah Conway PR Manager The Linux Foundation sconway@linuxfoundation.org (978) 578-5300 Cell Skype: sarah.k.conway --001a114089c466bb8f05161c6697 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great. I will post around 9 a.m. ET this morning.

=
Thanks,

On Fri, May 15, 2015 at 5:52 AM, Lengyel, Tamas <tlengyel@= novetta.com> wrote:
Hi Lars,
it looks good to me! ;)

<= /div>Thanks,
Tamas

On Fri, May 15,= 2015 at 10:39 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Tamas,
Sarah was making some minor changes. Please go to=C2=A0https://blog.xenproject.org/?p=3D10701&preview=3Dtrue= =C2=A0and log in via tlengyel and let us know whether we are ready to publi= sh. We probably want to do this around noon UK time
Lars

On 14 May 2015, at 17:45, Lars Kurth <lars.kurth.xen@gmail.com<= /a>> wrote:

Hi all,
I made some minor mods= :
* Inlined links
* Changed link [2] to a list of vulne= rabilities covering different hypervisor technologies

<= div>Sarah may go and make some minor edits. She may also add an image. We w= ould like to publish later tonight: if anyone one wants an additional ACK b= efore Sarah publishes, please let us know NOW!

Reg= ards
Lars

On 14= May 2015, at 17:07, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi Lars,
sounds good, thanks!

Tamas

= On Thu, May 14, 2015 at 5:20 PM, Lars Kurth <lars.kurth.xen@gmail= .com> wrote:
Looks fine to me
Unless there are further comment= s, I will encode this in the blog in an hour or so

@Tamas: I will create an account for you and publish under your name. You = will then have to reset your password

Cheers
=
Lars
=C2=A0

On 14 May 2015, at 14:32, Lengyel, Tamas <tlengyel@novetta.com> wrote:=

=EF=BB=BFThis is a gu= est blog post by Tamas K Lengyel, a long-time open source enthusiast and Xe= n contributor. Tamas works as Senior Security Researcher at Novetta, while = finishing his PhD on the topic of malware analysis and virtualization secur= ity at the University of Connecticut.
=C2=A0
-------------
Hardening Xen against VENOM-style attacks
=C2=A0
=C2=A0
The recent disclosure of the VENOM[1] bug affecting= major open-source hypervisors, such as KVM and Xen, has been circulating i= n the tech news as of 5/13/15, causing many to reevaluate their risks when = using cloud infrastructures. That is a very good thing indeed. Virtualizati= on and the cloud have been erroneously considered by many to be a silver bu= llet against intrusions and malware in general. The fact is that the cloud = is anything but a safe place. There are inherent risks in the cloud, thus i= t is very important to put those risks in context.
=C2=A0
=C2=A0
Hypervisors, same as any other complex software sys= tems, are prone to bugs and errors. VENOM in that sense is just another one= in the long list of vulnerabilities that have been popping up against hype= rvisors[2]. While VENOM is indeed a serious bug and can result in a VM esca= pe, which in turn can compromise all VMs on the host, it doesn=E2=80=99t ha= ve to be. In fact, VENOM-style attacks have been known for a long time. And= there are easy-to-deploy counter-measures to mitigate the risk of such exp= loits, natively available in both Xen and KVM (see RedHat=E2=80=99s blog po= st on the same topic[3]).
=C2=A0
=C2=A0
What is the root cause of VENOM? Emulation.
=C2=A0
=C2=A0
While modern systems come with a plethora of virtua= lization extensions, many components are still being emulated. The biggest = component of that are usually devices. Devices such as your network card, g= raphics card and your hard drive. While Linux comes with paravirtual (virtu= alization-aware) drivers to create such devices, emulation is often the onl= y solution to run operating systems that do not have such kernel drivers. T= his has been traditionally the case with Windows[4]. This emulation layer h= as been implemented in QEMU, which has caused VENOM and a handful of other = VM-escape bugs in recent years. However, QEMU is not the only place where e= mulation is used within Xen. For a variety of interrupts and timers, such a= s RTC, PIT, HPET, PMTimer, PIC, IOAPIC and LAPIC, there is a baked-in emula= tor in Xen itself for performance and scalability reasons[5]. As with QEMU,= this emulator has been just as exploitable[6]. This is simply because to p= rogram emulating devices and services properly is really complex and error-= prone.=C2=A0
=C2=A0
=C2=A0
This fact, that emulation is complex and error-pron= e, has been known for a long time. Back in 2011, the Blackhat talk on Virtu= noid[7] demonstrated such a VM escape attack against KVM, through QEMU. The= author of Virtunoid even cautioned there will be many other bugs of that n= ature found by researchers. Fast-forward 4 years and we now have VENOM.
=C2=A0
=C2=A0
The good news is there is an easy mitigation availa= ble for all present and future QEMU bugs, also mentioned in the original Xe= n Security Advisory[8]. It is called stubdomains[9]. Stubdomains can nip th= e whole class of vulnerabilities exposed by QEMU in the bud by moving QEMU = into a deprivileged domain of its own. Instead of having QEMU run as root i= n dom0, a stubdomain has access only to the VM it is providing emulation fo= r. Thus, an escape through QEMU will only land an attacker in a stubdomain,= without access to critical resources. Furthermore, QEMU in a stubdomain ru= ns on MiniOS, thus an attacker would only have a very limited environment t= o run code in (as in return-to-libc/ROP-style), having exactly the same lev= el of privilege as in the domain where the attack started. Nothing is to be= gained for a lot of work, effectively making the system as secure as it wo= uld be if only PV drivers were used.
=C2=A0
=C2=A0
One would think it is a complex process to take adv= antage of this protection, but in fact, it is very simple. Add the followin= g line to your Xen domain configuration and you gain immediate protection a= gainst VENOM, and the whole class of vulnerabilities brought to you by QEMU= :

device_model_stubdomain_override =3D 1=C2=A0
=C2=A0
However, as with most security systems, it comes at a cost. R= unning stubdomains requires a bit of extra memory as compared to the plain = QEMU process in dom0. This in turn can limit the number of VMs a cloud prov= ider may be able to sell, thus there is limited incentive on their end to e= nable this feature by default. Further complicating the picture is the fact= that this protection works best if all VMs on the server run with stubdoma= ins. Otherwise you may end up protecting your neighbors against an escape a= ttack from your domain, while not being protected from an escape attack fro= m theirs. It is thus no surprise if some users would not want to pay for th= is extra protection, even if it was available. However, for private clouds = and exclusive servers there is no reason why it shouldn=E2=80=99t be your d= efault setting.=C2=A0
________________
[1] http://= venom.crowdstrike.com/
[2] http://xe= nbits.xen.org/xsa/
[3] https://securityblog.redhat.com/2015/05/13/ven= om-dont-get-bitten/.
[4] Citrix recently open-sourced its Windows PV drivers so it is no lon= ger the case: http://www.xenproject.org/downloads/windows-pv= -drivers.html
[5] http://www.gossamer-threads.com/lists/xen/devel/34= 7492#347492
[6] http://xenbits.xen.org/xsa/advisory-105.html
[7] http://media.blackhat.com/bh-us-11/El= hage/BH_US_11_Elhage_Virtunoid_WP.pdf
[8] http://xenbits.xen.org/xsa/advisory-133.html
[9] http://wiki.xen.org/wiki/Device_Model_Stub_Domains

--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researc= her

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">
_______________________________________________
Publicity mailing listPubli= city@lists.xenproject.org
http://lists.xenproject.= org/cgi-bin/mailman/listinfo/publicity

=



--
3D"www.novetta.com"
Tamas K Lengyel
Senior Security Researcher

7921 Jones Branch Drive
McLean VA 22102
Email =C2=A0tleng= yel@novetta.com<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">





--

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica,sans-serif;font-size:1= 5px;vertical-align:baseline;white-space:pre-wrap;background-color:transpare= nt">3D"www.novetta.com"

Tamas K Lengyel

Senior Security Researcher=


<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">7921 Jones Branch Drive

<= span style=3D"color:rgb(147,149,152);font-family:Helvetica,sans-serif;verti= cal-align:baseline;white-space:pre-wrap">McLean VA 22102

<= span style=3D"color:rgb(0,100,182);font-family:Helvetica,sans-serif;vertica= l-align:baseline;white-space:pre-wrap">Email =C2=A0tlengyel@novetta.com


_______________________________________________
Publicity mailing list
Publicity@lists.xenprojec= t.org
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publ= icity




--
Sarah Conway
PR = Manager
The Linux Foundation
sconway@linuxfoundation.org
(= 978) 578-5300 =C2=A0Cell
Skype: =C2=A0sarah.k.conway
<= /div>
--001a114089c466bb8f05161c6697-- --===============2538894772734301765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============2538894772734301765==-- From publicity-bounces@lists.xenproject.org Tue May 19 22:51:11 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 19 May 2015 22:51:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YuqLv-0002s5-2E; Tue, 19 May 2015 22:51:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YuqLu-0002s0-AE for publicity@lists.xenproject.org; Tue, 19 May 2015 22:51:10 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id EC/23-03206-D5EBB555; Tue, 19 May 2015 22:51:09 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1432075868!19005318!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26843 invoked from network); 19 May 2015 22:51:08 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 May 2015 22:51:08 -0000 Received: by wibt6 with SMTP id t6so39871904wib.0 for ; Tue, 19 May 2015 15:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=MxwbFpZ4H/BXXVxhUQOVFLHj4jTtC3MqVgpHbg2frzg=; b=PDq00GEZiZWAln4+7BUki8eQAqRGvoHk8OjGx4NJ0AzcOqXDBNaOZ3nMdO/ALNyL05 ePaLuV2/VIetFGIBTlTdBfmv/T25ELxt6nEcvVVp2uZXz4QuRD+fPZVx1CjS4i1eygLn Cjeow+EXF4Z08KRd9gl3hfkRTBlxLqM9vkIQX7Ch23y87G1V3d+UOHZRUMKI/C6ngK1x K59Fg9sPcCGpSptLxMBxAfFEKMAckSR4d6OJn3bGzCbfONDHkmR09DnM3932HB/nfSS5 1Ia6OUmwCwiRepSSXC9P/XTEdeRDIqKoqUCCyKOGdAvnspjdHlrtSwKtHvceIVQDOKKg RyUw== X-Received: by 10.194.200.42 with SMTP id jp10mr57958157wjc.66.1432075868420; Tue, 19 May 2015 15:51:08 -0700 (PDT) Received: from [10.230.9.182] ([72.28.92.10]) by mx.google.com with ESMTPSA id o5sm611934wia.0.2015.05.19.15.51.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 May 2015 15:51:06 -0700 (PDT) From: Lars Kurth Message-Id: <6613DE6E-EF69-4472-9329-2496646AB5CD@gmail.com> Date: Tue, 19 May 2015 15:51:06 -0700 To: publicity@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Publicity] Post: Xen Project now in OpenStack Nova Hypervisor Driver Quality Group B - for review X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453994009021126357==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============1453994009021126357== Content-Type: multipart/alternative; boundary="Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF" --Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See https://blog.xenproject.org/?p=3D10727&preview=3Dtrue = Will publish later this evening Lars= --Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii See https://blog.xenproject.org/?p=10727&preview=true
Will publish later this evening
Lars
--Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF-- --===============1453994009021126357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============1453994009021126357==-- From publicity-bounces@lists.xenproject.org Tue May 19 22:51:11 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 19 May 2015 22:51:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YuqLv-0002s5-2E; Tue, 19 May 2015 22:51:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YuqLu-0002s0-AE for publicity@lists.xenproject.org; Tue, 19 May 2015 22:51:10 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id EC/23-03206-D5EBB555; Tue, 19 May 2015 22:51:09 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1432075868!19005318!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26843 invoked from network); 19 May 2015 22:51:08 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 May 2015 22:51:08 -0000 Received: by wibt6 with SMTP id t6so39871904wib.0 for ; Tue, 19 May 2015 15:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=MxwbFpZ4H/BXXVxhUQOVFLHj4jTtC3MqVgpHbg2frzg=; b=PDq00GEZiZWAln4+7BUki8eQAqRGvoHk8OjGx4NJ0AzcOqXDBNaOZ3nMdO/ALNyL05 ePaLuV2/VIetFGIBTlTdBfmv/T25ELxt6nEcvVVp2uZXz4QuRD+fPZVx1CjS4i1eygLn Cjeow+EXF4Z08KRd9gl3hfkRTBlxLqM9vkIQX7Ch23y87G1V3d+UOHZRUMKI/C6ngK1x K59Fg9sPcCGpSptLxMBxAfFEKMAckSR4d6OJn3bGzCbfONDHkmR09DnM3932HB/nfSS5 1Ia6OUmwCwiRepSSXC9P/XTEdeRDIqKoqUCCyKOGdAvnspjdHlrtSwKtHvceIVQDOKKg RyUw== X-Received: by 10.194.200.42 with SMTP id jp10mr57958157wjc.66.1432075868420; Tue, 19 May 2015 15:51:08 -0700 (PDT) Received: from [10.230.9.182] ([72.28.92.10]) by mx.google.com with ESMTPSA id o5sm611934wia.0.2015.05.19.15.51.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 May 2015 15:51:06 -0700 (PDT) From: Lars Kurth Message-Id: <6613DE6E-EF69-4472-9329-2496646AB5CD@gmail.com> Date: Tue, 19 May 2015 15:51:06 -0700 To: publicity@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Publicity] Post: Xen Project now in OpenStack Nova Hypervisor Driver Quality Group B - for review X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453994009021126357==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============1453994009021126357== Content-Type: multipart/alternative; boundary="Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF" --Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See https://blog.xenproject.org/?p=3D10727&preview=3Dtrue = Will publish later this evening Lars= --Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii See https://blog.xenproject.org/?p=10727&preview=true
Will publish later this evening
Lars
--Apple-Mail=_4591332C-8900-478B-9BDD-283B79E4ADBF-- --===============1453994009021126357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============1453994009021126357==-- From publicity-bounces@lists.xenproject.org Fri May 22 16:19:12 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 May 2015 16:19:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YvpfD-0002C4-CA; Fri, 22 May 2015 16:19:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YvpfC-0002Bz-FJ for publicity@lists.xenproject.org; Fri, 22 May 2015 16:19:10 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 8A/0B-03195-DF65F555; Fri, 22 May 2015 16:19:09 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1432311547!6793802!1 X-Originating-IP: [209.85.192.174] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21712 invoked from network); 22 May 2015 16:19:08 -0000 Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com) (209.85.192.174) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 May 2015 16:19:08 -0000 Received: by pdbnk13 with SMTP id nk13so23139989pdb.1 for ; Fri, 22 May 2015 09:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=DlrJZj3F1QeL4CTstbmMpAM8xTzvo6/FdJynHkTpqd8=; b=flB+Mij14TgQnnD3l2AWpXIPSrFc4My+Rgf+Wgs1YTk5r3+zOxsOHnDHTObVbyaXlP RmWwUALYJyRj14YJAoA4OIQlKnOrOpnj5A07ga36R6ktzKE6yr30jo8mkRi2BiX6roem 3lc3h8S2Wu4081Dcwk8wR3noxDAjHcq5VgXRZNY0W3F/8tCosZPcFLA7ok5WbWzCppLM sEsN9NKAXhHFLHTOgKNG6Ab2vrfsQUEcag/eo62xKvIsHYCJ4XR4lY7M1IHNnYhK2Z9y EZoT9FsHsjt5DTGyYq68APyEphBKKF7S/foQVhpAY/lSSvkF/eOBm5TWJrLw5fL1s1PE Z5/Q== X-Received: by 10.68.57.229 with SMTP id l5mr17200681pbq.130.1432311546718; Fri, 22 May 2015 09:19:06 -0700 (PDT) Received: from [192.168.11.203] ([64.114.255.126]) by mx.google.com with ESMTPSA id nt15sm2584053pdb.14.2015.05.22.09.19.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 May 2015 09:19:05 -0700 (PDT) From: Lars Kurth Message-Id: Date: Fri, 22 May 2015 09:19:03 -0700 To: publicity@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Publicity] Clear Containers - Intel's KVM/KVMTool based container distro - what are the implications? X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6373836909907394694==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6373836909907394694== Content-Type: multipart/alternative; boundary="Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5" --Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I just came across = http://www.infoworld.com/article/2925038/linux/intel-takes-on-coreos-with-= its-own-container-based-linux.html = http://lwn.net/SubscriberLink/644675/54520a696ff9cddc/ = and am wondering what the implications are. Interesting portions of this are: Many people who advocate for containers start by saying that virtual = machines are expensive and slow to start and that containers provide a = more efficient alternative. The usual counterpoint is about how secure = kernel containers really are against adversarial users with an arsenal = of exploits in their pockets. Reasonable people can argue for hours on = this topic but the reality is that quite a few potential users of = containers see this as a showstopper. We (the Intel Clear Containers group) are taking a little bit of a = different tack on the security of containers by going back to the basic = question: how expensive is virtual-machine technology, really? = Performance in this regard is primarily measured using two metrics: = startup time and memory overhead. The first is about how quickly your = data center can respond to an incoming request (say a user logs into = your email system); the second is about how many containers you can pack = on a single server. ... To provide a preview of the results: we can launch such a secured = container that uses virtualization technology in under 150 milliseconds, = and the per-container memory overhead is roughly 18 to 20MB (this means = you can run over 3500 of these on a server with 128GB of RAM). --- I am wondering how the typical unikernel compares in terms of start-up = time and memory overhead.=20 Regards Lars= --Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,
I just came across
http://www.infoworld.com/article/2925038/linux/intel-takes-on-c= oreos-with-its-own-container-based-linux.html
http://lwn.net/SubscriberLink/644675/54520a696ff9cddc/
and am wondering what the implications are.

Interesting portions of this = are:

Many people who advocate for = containers start by saying that virtual machines are expensive and slow = to start and that containers provide a more = efficient alternative. The usual counterpoint is about how secure kernel = containers really are against adversarial users with an arsenal of = exploits in their pockets. Reasonable people can argue for hours on this = topic but the reality is that quite a few potential = users of containers see this as a showstopper.

We = (the Intel Clear Containers group) are taking a little bit of a = different tack on the security of containers by going back to the basic = question: how expensive is virtual-machine technology, really? = Performance in this regard is primarily measured using two metrics: = startup time and memory overhead. The first is about how quickly your = data center can respond to an incoming request (say a user logs into = your email system); the second is about how many containers you can pack = on a single server.

...

To = provide a preview of the results: we can launch such a secured container = that uses virtualization technology in under 150 milliseconds, and the = per-container memory overhead is roughly 18 to 20MB (this means you can = run over 3500 of these on a server with 128GB of = RAM).

---

I am = wondering how the typical unikernel compares in terms of start-up = time and memory overhead. 

Regards
Lars
= --Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5-- --===============6373836909907394694== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6373836909907394694==-- From publicity-bounces@lists.xenproject.org Fri May 22 16:19:12 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 May 2015 16:19:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YvpfD-0002C4-CA; Fri, 22 May 2015 16:19:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YvpfC-0002Bz-FJ for publicity@lists.xenproject.org; Fri, 22 May 2015 16:19:10 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 8A/0B-03195-DF65F555; Fri, 22 May 2015 16:19:09 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1432311547!6793802!1 X-Originating-IP: [209.85.192.174] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21712 invoked from network); 22 May 2015 16:19:08 -0000 Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com) (209.85.192.174) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 May 2015 16:19:08 -0000 Received: by pdbnk13 with SMTP id nk13so23139989pdb.1 for ; Fri, 22 May 2015 09:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=DlrJZj3F1QeL4CTstbmMpAM8xTzvo6/FdJynHkTpqd8=; b=flB+Mij14TgQnnD3l2AWpXIPSrFc4My+Rgf+Wgs1YTk5r3+zOxsOHnDHTObVbyaXlP RmWwUALYJyRj14YJAoA4OIQlKnOrOpnj5A07ga36R6ktzKE6yr30jo8mkRi2BiX6roem 3lc3h8S2Wu4081Dcwk8wR3noxDAjHcq5VgXRZNY0W3F/8tCosZPcFLA7ok5WbWzCppLM sEsN9NKAXhHFLHTOgKNG6Ab2vrfsQUEcag/eo62xKvIsHYCJ4XR4lY7M1IHNnYhK2Z9y EZoT9FsHsjt5DTGyYq68APyEphBKKF7S/foQVhpAY/lSSvkF/eOBm5TWJrLw5fL1s1PE Z5/Q== X-Received: by 10.68.57.229 with SMTP id l5mr17200681pbq.130.1432311546718; Fri, 22 May 2015 09:19:06 -0700 (PDT) Received: from [192.168.11.203] ([64.114.255.126]) by mx.google.com with ESMTPSA id nt15sm2584053pdb.14.2015.05.22.09.19.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 May 2015 09:19:05 -0700 (PDT) From: Lars Kurth Message-Id: Date: Fri, 22 May 2015 09:19:03 -0700 To: publicity@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Publicity] Clear Containers - Intel's KVM/KVMTool based container distro - what are the implications? X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6373836909907394694==" Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org --===============6373836909907394694== Content-Type: multipart/alternative; boundary="Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5" --Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I just came across = http://www.infoworld.com/article/2925038/linux/intel-takes-on-coreos-with-= its-own-container-based-linux.html = http://lwn.net/SubscriberLink/644675/54520a696ff9cddc/ = and am wondering what the implications are. Interesting portions of this are: Many people who advocate for containers start by saying that virtual = machines are expensive and slow to start and that containers provide a = more efficient alternative. The usual counterpoint is about how secure = kernel containers really are against adversarial users with an arsenal = of exploits in their pockets. Reasonable people can argue for hours on = this topic but the reality is that quite a few potential users of = containers see this as a showstopper. We (the Intel Clear Containers group) are taking a little bit of a = different tack on the security of containers by going back to the basic = question: how expensive is virtual-machine technology, really? = Performance in this regard is primarily measured using two metrics: = startup time and memory overhead. The first is about how quickly your = data center can respond to an incoming request (say a user logs into = your email system); the second is about how many containers you can pack = on a single server. ... To provide a preview of the results: we can launch such a secured = container that uses virtualization technology in under 150 milliseconds, = and the per-container memory overhead is roughly 18 to 20MB (this means = you can run over 3500 of these on a server with 128GB of RAM). --- I am wondering how the typical unikernel compares in terms of start-up = time and memory overhead.=20 Regards Lars= --Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,
I just came across
http://www.infoworld.com/article/2925038/linux/intel-takes-on-c= oreos-with-its-own-container-based-linux.html
http://lwn.net/SubscriberLink/644675/54520a696ff9cddc/
and am wondering what the implications are.

Interesting portions of this = are:

Many people who advocate for = containers start by saying that virtual machines are expensive and slow = to start and that containers provide a more = efficient alternative. The usual counterpoint is about how secure kernel = containers really are against adversarial users with an arsenal of = exploits in their pockets. Reasonable people can argue for hours on this = topic but the reality is that quite a few potential = users of containers see this as a showstopper.

We = (the Intel Clear Containers group) are taking a little bit of a = different tack on the security of containers by going back to the basic = question: how expensive is virtual-machine technology, really? = Performance in this regard is primarily measured using two metrics: = startup time and memory overhead. The first is about how quickly your = data center can respond to an incoming request (say a user logs into = your email system); the second is about how many containers you can pack = on a single server.

...

To = provide a preview of the results: we can launch such a secured container = that uses virtualization technology in under 150 milliseconds, and the = per-container memory overhead is roughly 18 to 20MB (this means you can = run over 3500 of these on a server with 128GB of = RAM).

---

I am = wondering how the typical unikernel compares in terms of start-up = time and memory overhead. 

Regards
Lars
= --Apple-Mail=_E33EDF93-8500-4391-BB05-929861742CD5-- --===============6373836909907394694== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity --===============6373836909907394694==-- From publicity-bounces@lists.xenproject.org Sun May 24 16:34:30 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 24 May 2015 16:34:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YwYr7-0006Ks-Q9; Sun, 24 May 2015 16:34:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YwYr6-0006Kn-Sq for publicity@lists.xenproject.org; Sun, 24 May 2015 16:34:28 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id E6/6C-03206-49DF1655; Sun, 24 May 2015 16:34:28 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1432485267!20326940!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4019 invoked from network); 24 May 2015 16:34:27 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 May 2015 16:34:27 -0000 Received: from [10.200.1.187] (athedsl-4517800.home.otenet.gr [94.71.219.176]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0e2001b1; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 24 May 2015 17:34:27 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Anil Madhavapeddy In-Reply-To: Date: Sun, 24 May 2015 17:34:26 +0100 Message-Id: <2752A7A8-5095-4526-8005-429230C43280@recoil.org> References: To: Richard Mortier X-Mailer: Apple Mail (2.2098) Cc: Lars Kurth , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Clear Containers - Intel's KVM/KVMTool based container distro - what are the implications? X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org > On 23 May 2015, at 09:56, Richard Mortier wrote: > > On 22 May 2015 at 17:19, Lars Kurth wrote: >> To provide a preview of the results: we can launch such a secured container >> that uses virtualization technology in under 150 milliseconds, and the >> per-container memory overhead is roughly 18 to 20MB (this means you can run >> over 3500 of these on a server with 128GB of RAM). >> >> --- >> >> I am wondering how the typical unikernel compares in terms of start-up time >> and memory overhead. > > Define "typical" :) > > For MirageOS, I think those are comparable, though MirageOS can go > lower in terms of memory use (16MiB used in NSDI'15; on-disk size of a > presentation unikernel typically under 10MB -- NSDI'15 presentation > claims 2MB) and faster in terms of startup (20-30ms claimed on x86 in > the NSDI'15 paper, and 30-45ms claimed in the presentation -- Anil, is > there really a discrepancy?). I think the discrepancy was due to SYN caching or just a clean boot. I wonder if their launch times also include setting up network bridging as well. One benefit of unikernels is that we dont have to setup a union mount filesystem to boot -- so no touching disk. -a _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity From publicity-bounces@lists.xenproject.org Sun May 24 16:34:30 2015 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sun, 24 May 2015 16:34:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YwYr7-0006Ks-Q9; Sun, 24 May 2015 16:34:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YwYr6-0006Kn-Sq for publicity@lists.xenproject.org; Sun, 24 May 2015 16:34:28 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id E6/6C-03206-49DF1655; Sun, 24 May 2015 16:34:28 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-9.tower-27.messagelabs.com!1432485267!20326940!1 X-Originating-IP: [5.153.225.51] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4019 invoked from network); 24 May 2015 16:34:27 -0000 Received: from bark.recoil.org (HELO bark.recoil.org) (5.153.225.51) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 May 2015 16:34:27 -0000 Received: from [10.200.1.187] (athedsl-4517800.home.otenet.gr [94.71.219.176]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 0e2001b1; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Sun, 24 May 2015 17:34:27 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Anil Madhavapeddy In-Reply-To: Date: Sun, 24 May 2015 17:34:26 +0100 Message-Id: <2752A7A8-5095-4526-8005-429230C43280@recoil.org> References: To: Richard Mortier X-Mailer: Apple Mail (2.2098) Cc: Lars Kurth , "publicity@lists.xenproject.org" Subject: Re: [Publicity] Clear Containers - Intel's KVM/KVMTool based container distro - what are the implications? X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "List for Xen Publicity, PR and events" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: publicity-bounces@lists.xenproject.org Errors-To: publicity-bounces@lists.xenproject.org > On 23 May 2015, at 09:56, Richard Mortier wrote: > > On 22 May 2015 at 17:19, Lars Kurth wrote: >> To provide a preview of the results: we can launch such a secured container >> that uses virtualization technology in under 150 milliseconds, and the >> per-container memory overhead is roughly 18 to 20MB (this means you can run >> over 3500 of these on a server with 128GB of RAM). >> >> --- >> >> I am wondering how the typical unikernel compares in terms of start-up time >> and memory overhead. > > Define "typical" :) > > For MirageOS, I think those are comparable, though MirageOS can go > lower in terms of memory use (16MiB used in NSDI'15; on-disk size of a > presentation unikernel typically under 10MB -- NSDI'15 presentation > claims 2MB) and faster in terms of startup (20-30ms claimed on x86 in > the NSDI'15 paper, and 30-45ms claimed in the presentation -- Anil, is > there really a discrepancy?). I think the discrepancy was due to SYN caching or just a clean boot. I wonder if their launch times also include setting up network bridging as well. One benefit of unikernels is that we dont have to setup a union mount filesystem to boot -- so no touching disk. -a _______________________________________________ Publicity mailing list Publicity@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity