From publicity-bounces@lists.xenproject.org Wed Apr 13 15:24:36 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 15:24:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqMeh-00008i-Ow; Wed, 13 Apr 2016 15:24:35 +0000 Received: from mail6.bemta6.messagelabs.com ([85.158.143.247]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqMeg-00008c-G8 for publicity@lists.xenproject.org; Wed, 13 Apr 2016 15:24:34 +0000 Received: from [85.158.143.35] by server-1.bemta-6.messagelabs.com id A4/7B-18833-FA46E075; Wed, 13 Apr 2016 15:24:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleJIrShJLcpLzFFi42Lxqg0y0F2bwhd u0LVLxeJ331pGB0aPwx+usAQwRrFm5iXlVySwZny6o1Dw8zRjxd7WV6wNjCfWMnYxcnEICcxi lDi85hYziMMi0MAqcb3/BQuIIyEwh1Wiv+0BUBknkBMj8frJdVYIu1ri8pXFYHEhAXWJe4tus 0OM+sYo0fPnNjNIglkgQWLblmdgRbwCehKvbl0GaxYWsJE4dvIemM0moC2x6cYDsHpOgUCJGQ ta2UBsFgFVifuLr7JBzAmQWNk+iwlijo3E/4cwy3pYJP7MeAu0gINDBGhQZ5cBxHGyErt/P2K awCg0C8kZs5CcARHXlli28DUzjH390gVGTHEtifczL7EvYGRbxahenFpUllqka6iXVJSZnlGS m5iZo2toYKaXm1pcnJiempOYVKyXnJ+7iREYHQxAsINx53OnQ4ySHExKorzbgvnChfiS8lMqM xKLM+KLSnNSiw8xynBwKEnwuiUD5QSLUtNTK9Iyc4BxCpOW4OBREuFNBEnzFhck5hZnpkOkTj HqcmyZem8tkxBLXn5eqpQ4bwhIkQBIUUZpHtwIWMq4xCgrJczLCHSUEE9BalFuZgmq/CtGcQ5 GJWHeFJApPJl5JXCbXgEdwQR0RNk7XpAjShIRUlINjLkv13Jc1HQvSpo5/wpHb/QW9b+nDHRE /I7yFj2OXLu09T3L14yu98bH5iZfa3xbf6J4hf+rF4debAl28Q583HfIelF1V+XjiNrpn5dId Husr2kXuyIpsPbjowLLxjvLL91fO1HTumHuNs3nf3x9DYyvWRzY0Pdj8m1TQybxahtb1wmrGZ 4rvlFiKc5INNRiLipOBABePUlVFAMAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1460561069!9114333!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27715 invoked from network); 13 Apr 2016 15:24:29 -0000 Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by server-9.tower-21.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 15:24:29 -0000 Received: by mail-wm0-f48.google.com with SMTP id v188so181076562wme.1 for ; Wed, 13 Apr 2016 08:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ca5ZPRZf1cUMIZMMn1Uf8ybaj5g14R8F1QGbq1GFNVo=; b=bcz09As+lVaCmt3o+HwI4No73oXR166lzmICYMLLTajMJTmIX2euPcJuNTQUUwum6f Bmce/59szQUQkZil43eutLMxAd/DqRCjp9cPnA9cjAC9h6UfVNUuH9Rkye+1ukGLqXEM z9cCdjSbLjFliuyVzUDNzBu8hf+GjGQVB0wXcsjhkesTvQI0UjtusE4TebXyO7Ito69D yyksqgEVYauGFVAuyJZ5xX2earhb9TTIhtay3QhzANfUG/1MtnXVGYewSS1on/Ao5k7U YRq/8GOPC0xh6XuVPoiXRumWaBDwizVGrHotHyJuxGQeywPNHeRBvk7GBvWi4ynUrdkQ 09PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ca5ZPRZf1cUMIZMMn1Uf8ybaj5g14R8F1QGbq1GFNVo=; b=HAE7PlDSkbjdJHNfwAOJ9UqbCVVZYYRW2KZUHE6eycgD7B3wROuyXVRs5dvubpr/wM lK2d8vbbYJogArhKiqnNLGt6unqoPtg//10HCqhv7VwdS/7VBdNIEOyaZoAk0CAn9WzW mNaYVZqo62trF212neE70bWYXd5hJMkYU+mN20z+pcGoN3iApCjx6ZFEXM4ryQtdXqPR TFND5vAlvaRVAJphL6pC5vOUMgzoJA6sLzOaG2aexhOEXNIGAwjuF7KpYW8z/oKtcqMn 0xaekle3lK/w48z638sMfIx0S3YtHasq/Rctx1w1ciP27SlctGD6fQjiaYNpmvp/ImpM 4MfQ== X-Gm-Message-State: AOPr4FWyP1TPeQb2U789OxrkEpFYh/kxepA9DGSy5S3xHQ9JzbHYyArrMtsyKpXtUGd6IQ== X-Received: by 10.194.90.229 with SMTP id bz5mr11258115wjb.143.1460561067765; Wed, 13 Apr 2016 08:24:27 -0700 (PDT) Received: from [192.168.0.9] (5ec0a29f.skybroadband.com. [94.192.162.159]) by smtp.gmail.com with ESMTPSA id l124sm1782602wmf.11.2016.04.13.08.24.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 08:24:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Wed, 13 Apr 2016 16:24:25 +0100 Message-Id: References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2104) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============2521327380458857414==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============2521327380458857414== Content-Type: multipart/alternative; boundary="Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375" --Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tamas, apologies. I missed this in my inbox ... I made a few minor suggestions: mainly shortening some sentences.=20 There are also a couple of questions Do you want me to upload this to the blog (under your username)? Where = do you want to insert the png's? > On 25 Jan 2016, at 20:51, Lengyel, Tamas wrote: >=20 > Hi all, > here is an updated version. Also, a couple pictures that could be used = as illustrations. Feel free to punch it up as needed ;) >=20 > Tamas >=20 > Stealthy monitoring with Xen altp2m >=20 > One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer "In Xen 4.6 which was was released last autumn" > several new features have been introduced that make this subsystem = better; a cleaned-up, optimized API and ARM support being just some of = the biggest items on this list. As part of this release of Xen, a new = and unique feature was also successfully added by a team from Intel that = make stealthy monitoring even better on Xen: altp2m. In this blog entry = we will take a look at what it's all about. >=20 > In Xen's terminology, p2m stands for the memory management layer that = handles the translation from guest [p]hysical memory to [m]achine = physical. This translation is critical for safely partitioning the real = memory of machine between Xen and the various VMs running as to ensure a = VM can't simply access the memory of another. There are several = implementations of this There are several implementations of this mechanism, > including one with hardware support via Intel Extended Page Tables = (EPT) available to HVM (and PVH) guests and PVH . > , called Hardware Assisted Paging (hap) in Xen's terminology. In Xen's terminology, this is called Hardware Assisted Paging (hap). > In this implementation the hypervisor maintains a second pagetable, = similar to the one in 64-bit operating systems use, dedicated to running = the p2m translation. All (open-source) hypervisors that use this = hardware assisted paging method use a single EPT per virtual machine to = handle this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards. >=20 > Xen altp2m is the first implementation which changes this setup by = allowing Xen to create more then one EPT for each guest. Interestingly, = the Intel hardware has been capable of maintaining up to 512 EPT = pointers in the VMCS since the first introduction of EPT; however, noone = made use of this capability until now. This changed in Xen 4.6, where we = can now create of up to 10 EPTs per guest. The primary reason for this = extension is of course the new #VE and VMFUNC extensions that were = released in the Skylake generation of CPUs (which is worth a whole = blog-entry on its own), but it can also be used by external monitoring = applications via the Xen vm_event system. It can also be used by external monitoring applications via the Xen = vm_event system. Add a sub-headline: Why alt2pm is a game-changer >=20 > Why this feature is a game-changer for applications performing purely = external monitoring is because it simplifies the monitoring process of = multi-vCPU guests. Alt2pm is a game-changer for applications performing purely external = monitoring is because it simplifies the monitoring process of multi-vCPU = guests. > The EPT layer has been successfully used in stealthy monitoring = applications to track the memory accesses made by the VM from a safe = vantage point by restricting the type of access the VM may perform on = various memory pages. Since EPT permission violations trap into the = hypervisor, the VM would receive no indication that anything out of the = ordinary has happened. While the method allowed for stealthy tracing of = R/W/X memory accesses of the guest, the memory permission needs to be = relaxed in order to allow the guest to continue execution. When a single = EPT is shared across multiple running vCPUs, relaxing the permissions to = allow one vCPU to continue may inadvertantly allow another one to = perform the memory access we would otherwise want to track. While under = normal circumstances such race-condition may rarely occur, malicious = code could easily use this to hide some of its actions from a monitoring = application. >=20 > Solutions to this problem exist already. For example we can pause all = vCPUs while the one violating the access is singlestepped. This approach = however introduces heavy overhead just to avoid a race-condition that = may rarely occur in practice. Alternatively, one could emulate the = instruction that was violating the EPT permission without relaxing the = EPT access permissions, as Xen's built-in emulator doesn't use EPT to = access the guest memory. This solution, while supported in Xen, is not = particularly ideal either as Xen's emulator is incomplete and is known = to have issues that can lead to guest instability [2]. Furthermore, over = the years emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available. >=20 > Xen's altp2m system changes this problem quite significantly. By = having multiple EPTs we can have differing access permissions defined in = each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution. >=20 Add a sub-headline: Other introspection methods for stealthy monitoring > Of course, EPT based monitoring is not the only introspecting = technique used for stealthy monitoring. For example, the Xen based = DRAKVUF Dynamic Malware Analysis [4] uses it in combination with an = additional technique to maximum effect. > The main motivation for that is because EPT based monitoring is known = to introduce significant overhead, even with altp2m: the granularity of = the monitoring is that of a memory page (4KB). This sentence is a bit convoluted and I lost you here. Not quite sure = what you are trying to say > If the monitoring application is really just interested, for example, = when a function-entry point is called, EPT based monitoring creates a = lot of "false" events when that page is accessed for the rest of the = function's code. Again, something seems to be missing here and I am struggling to = understand what you are trying to say > Fortunately, this can be avoided by enabling the trapping of debug = instructions into the hypervisor, a built-in feature of Intel CPUs that = Xen exposes to third-party applications. This method is used in DRAKVUF, = which writes breakpoint instructions into the guests' memory at = code-locations of interest. Since we will only get an event for = precisely the code-location we are interested in this method effectively = reduces the overhead. However, the trade-off is that unlike EPT = permissions the breakpoints are now visible to the guest. Thus, to hide = the presence of the breakpoints from the guest, these pages need to get = further protected by restricting the pages to be execute-only in the = EPT. This allows DRAKVUF to remove the breakpoints before in-guest = code-integrity checking mechanisms (like Windows Patchguard) can access = the page. While with altp2m the EPT permissions can be safely used with = multi-vCPU systems, using breakpoints similarly presents a = race-condition: the breakpoint hit by one vCPU has to be removed to = allow the guest to execute the instruction that was originally = overwritten, potentially allowing another vCPU to do so as well without = notice. >=20 > Fortunately, altp2m has another neat feature that can be used to solve = this problem. Beside allowing for changing the memory permissions in the = different altp2m views, it also allows to change the mapping itself! The = same guest physical memory can be setup to be backed by different pages = in the different views. With this feature we can really thing of guest = physical assuming: thing=3Dthink > memory as "virtual": where it is mapped really depends on which view = the vCPU is running on. Using this feature allows us to hide the = presence of the breakpoints in a brand new way. To do this, first we = create a complete shadow copy of the memory page where a breakpoint is = going to be written and only write the breakpoint into this shadow copy. = Now, using altp2m, we setup a view where the guest physical memory of = the page gets mapped to our shadow copy. The guest continues to access = its physical memory as before, but underneath it is now using the = trapped shadow copy. When the breakpoint is hit, or if something is = trying to scan the code, we simply switch the view to the un-altered = view for the duration of a singlestep, then switch back to the trapped = view. This allows us to hide the presence of the breakpoints specific to = each vCPU! All without having pause any of the other vCPUs or having to = emulate. The first open-source implementation of this tracing has been = already merged into the DRAKVUF Malware Analysis System and is available = as a reference implementation for those interested in more details. >=20 > As we can see, Xen continues to be on the forefront of advancing the = development of virtualization based security application and allowing = third-party tools to create some very exotic setups. This flexibility is = what's so great about Xen and why it will continue to be a trend-setter = for the foreseeable future. >=20 Add a sub-headline: References > [1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection = > [2] http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.html = > [3] = https://blog.xenproject.org/2015/05/14/hardening-hypervisors-against-venom= -style-attacks/ = > [4] http://drakvuf.com > --Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tamas,

apologies. I missed this in my inbox ...

I made a few minor = suggestions: mainly shortening some sentences. 
There are also a couple of questions

Do you want me to upload this to the = blog (under your username)? Where do you want to insert the = png's?

On 25 Jan 2016, at 20:51, Lengyel, Tamas = <tlengyel@novetta.com> wrote:

Hi all,
here is an updated version. Also, a couple pictures that = could be used as illustrations. Feel free to punch it up as needed ;)

Tamas


Stealthy monitoring with Xen altp2m

One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer =

"In Xen 4.6 = which was was released last autumn"

several new features have been introduced that make this = subsystem better; a cleaned-up, optimized API and ARM support being just = some of the biggest items on this list. As part of this release of Xen, = a new and unique feature was also successfully added by a team from = Intel that make stealthy monitoring even better on Xen: altp2m. In this = blog entry we will take a look at what it's all about.

In Xen's terminology, p2m stands for the memory management = layer that handles the translation from guest [p]hysical memory to = [m]achine physical. This translation is critical for safely partitioning = the real memory of machine between Xen and the various VMs running as to = ensure a VM can't simply access the memory of another. There are several = implementations of this

There are several implementations of this mechanism,

including one = with hardware support via Intel Extended Page Tables (EPT) available to = HVM (and PVH) guests

and PVH <guests>.

, called Hardware Assisted Paging = (hap) in Xen's terminology.

In Xen's terminology, this is called Hardware = Assisted Paging (hap).

In = this implementation the hypervisor maintains a second pagetable, similar = to the one in 64-bit operating systems use, dedicated to running the p2m = translation. All (open-source) hypervisors that use this hardware = assisted paging method use a single EPT per virtual machine to handle = this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards.

Xen altp2m is the first implementation which = changes this setup by allowing Xen to create more then one EPT for each = guest. Interestingly, the Intel hardware has been capable of maintaining = up to 512 EPT pointers in the VMCS since the first introduction of EPT; = however, noone made use of this capability until now. This changed in = Xen 4.6, where we can now create of up to 10 EPTs per guest. The primary = reason for this extension is of course the new #VE and VMFUNC extensions = that were released in the Skylake generation of CPUs (which is worth a = whole blog-entry on its own), but it can also be used by external = monitoring applications via the Xen vm_event system.

It = can also be used by external monitoring applications via the Xen = vm_event system.

Add a sub-headline: = Why alt2pm is a game-changer


Why this feature is a game-changer for = applications performing purely external monitoring is because it = simplifies the monitoring process of multi-vCPU guests. =

Alt2pm is a = game-changer for applications performing purely external monitoring is = because it simplifies the monitoring process of multi-vCPU = guests.

The EPT layer = has been successfully used in stealthy monitoring applications to track = the memory accesses made by the VM from a safe vantage point by = restricting the type of access the VM may perform on various memory = pages. Since EPT permission violations trap into the hypervisor, the VM = would receive no indication that anything out of the ordinary has = happened. While the method allowed for stealthy tracing of R/W/X memory = accesses of the guest, the memory permission needs to be relaxed in = order to allow the guest to continue execution. When a single EPT is = shared across multiple running vCPUs, relaxing the permissions to allow = one vCPU to continue may inadvertantly allow another one to perform the = memory access we would otherwise want to track. While under normal = circumstances such race-condition may rarely occur, malicious code could = easily use this to hide some of its actions from a monitoring = application.

Solutions to this problem = exist already. For example we can pause all vCPUs while the one = violating the access is singlestepped. This approach however introduces = heavy overhead just to avoid a race-condition that may rarely occur in = practice. Alternatively, one could emulate the instruction that was = violating the EPT permission without relaxing the EPT access = permissions, as Xen's built-in emulator doesn't use EPT to access the = guest memory. This solution, while supported in Xen, is not particularly = ideal either as Xen's emulator is incomplete and is known to have issues = that can lead to guest instability [2]. Furthermore, over the years = emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available.

Xen's altp2m system changes this problem quite significantly. = By having multiple EPTs we can have differing access permissions defined = in each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution.


Add = a sub-headline: Other introspection methods for stealthy = monitoring

Of = course, EPT based monitoring is not the only introspecting technique = used for stealthy monitoring. For example, the Xen based DRAKVUF Dynamic = Malware Analysis [4] uses it in combination with an additional technique = to maximum effect.

The main motivation for that is = because EPT based monitoring is known to introduce significant overhead, = even with altp2m: the granularity of the monitoring is that of a memory = page (4KB).

This sentence is a bit convoluted and I lost you = here. Not quite sure what you are trying to say

If the monitoring application is = really just interested, for example, when a function-entry point is = called, EPT based monitoring creates a lot of "false" events when that = page is accessed for the rest of the function's code. =

Again, = something seems to be missing here and I am struggling to understand =  what you are trying to say

Fortunately, this can be avoided by enabling the trapping of = debug instructions into the hypervisor, a built-in feature of Intel CPUs = that Xen exposes to third-party applications. This method is used in = DRAKVUF, which writes breakpoint instructions into the guests' memory at = code-locations of interest. Since we will only get an event for = precisely the code-location we are interested in this method effectively = reduces the overhead. However, the trade-off is that unlike EPT = permissions the breakpoints are now visible to the guest. Thus, to hide = the presence of the breakpoints from the guest, these pages need to get = further protected by restricting the pages to be execute-only in the = EPT. This allows DRAKVUF to remove the breakpoints before in-guest = code-integrity checking mechanisms (like Windows Patchguard) can access = the page. While with altp2m the EPT permissions can be safely used with = multi-vCPU systems, using breakpoints similarly presents a = race-condition: the breakpoint hit by one vCPU has to be removed to = allow the guest to execute the instruction that was originally = overwritten, potentially allowing another vCPU to do so as well without = notice.

Fortunately, altp2m has another = neat feature that can be used to solve this problem. Beside allowing for = changing the memory permissions in the different altp2m views, it also = allows to change the mapping itself! The same guest physical memory can = be setup to be backed by different pages in the different views. With = this feature we can really thing of guest physical =

assuming: = thing=3Dthink

memory as  "virtual": where it is mapped really depends = on which view the vCPU is running on. Using this feature allows us to = hide the presence of the breakpoints in a brand new way. To do this, = first  we create a complete shadow copy of the memory page where a = breakpoint is going to be written and only write the breakpoint into = this shadow copy. Now, using altp2m, we setup a view where the guest = physical memory of the page gets mapped to our shadow copy. The guest = continues to access its physical memory as before, but underneath it is = now using the trapped shadow copy. When the breakpoint is hit, or if = something is trying to scan the code, we simply switch the view to the = un-altered view for the duration of a singlestep, then switch back to = the trapped view. This allows us to hide the presence of the breakpoints = specific to each vCPU! All without having pause any of the other vCPUs = or having to emulate. The first open-source implementation of this = tracing has been already merged into the DRAKVUF Malware Analysis System = and is available as a reference implementation for those interested in = more details.

As we can see, Xen continues = to be on the forefront of advancing the development of virtualization = based security application and allowing third-party tools to create some = very exotic setups. This flexibility is what's so great about Xen and = why it will continue to be a trend-setter for the foreseeable future.


Add a sub-headline: References


= --Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375-- --===============2521327380458857414== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============2521327380458857414==-- From publicity-bounces@lists.xenproject.org Wed Apr 13 15:24:36 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 15:24:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqMeh-00008i-Ow; Wed, 13 Apr 2016 15:24:35 +0000 Received: from mail6.bemta6.messagelabs.com ([85.158.143.247]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqMeg-00008c-G8 for publicity@lists.xenproject.org; Wed, 13 Apr 2016 15:24:34 +0000 Received: from [85.158.143.35] by server-1.bemta-6.messagelabs.com id A4/7B-18833-FA46E075; Wed, 13 Apr 2016 15:24:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleJIrShJLcpLzFFi42Lxqg0y0F2bwhd u0LVLxeJ331pGB0aPwx+usAQwRrFm5iXlVySwZny6o1Dw8zRjxd7WV6wNjCfWMnYxcnEICcxi lDi85hYziMMi0MAqcb3/BQuIIyEwh1Wiv+0BUBknkBMj8frJdVYIu1ri8pXFYHEhAXWJe4tus 0OM+sYo0fPnNjNIglkgQWLblmdgRbwCehKvbl0GaxYWsJE4dvIemM0moC2x6cYDsHpOgUCJGQ ta2UBsFgFVifuLr7JBzAmQWNk+iwlijo3E/4cwy3pYJP7MeAu0gINDBGhQZ5cBxHGyErt/P2K awCg0C8kZs5CcARHXlli28DUzjH390gVGTHEtifczL7EvYGRbxahenFpUllqka6iXVJSZnlGS m5iZo2toYKaXm1pcnJiempOYVKyXnJ+7iREYHQxAsINx53OnQ4ySHExKorzbgvnChfiS8lMqM xKLM+KLSnNSiw8xynBwKEnwuiUD5QSLUtNTK9Iyc4BxCpOW4OBREuFNBEnzFhck5hZnpkOkTj HqcmyZem8tkxBLXn5eqpQ4bwhIkQBIUUZpHtwIWMq4xCgrJczLCHSUEE9BalFuZgmq/CtGcQ5 GJWHeFJApPJl5JXCbXgEdwQR0RNk7XpAjShIRUlINjLkv13Jc1HQvSpo5/wpHb/QW9b+nDHRE /I7yFj2OXLu09T3L14yu98bH5iZfa3xbf6J4hf+rF4debAl28Q583HfIelF1V+XjiNrpn5dId Husr2kXuyIpsPbjowLLxjvLL91fO1HTumHuNs3nf3x9DYyvWRzY0Pdj8m1TQybxahtb1wmrGZ 4rvlFiKc5INNRiLipOBABePUlVFAMAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1460561069!9114333!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27715 invoked from network); 13 Apr 2016 15:24:29 -0000 Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by server-9.tower-21.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 15:24:29 -0000 Received: by mail-wm0-f48.google.com with SMTP id v188so181076562wme.1 for ; Wed, 13 Apr 2016 08:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ca5ZPRZf1cUMIZMMn1Uf8ybaj5g14R8F1QGbq1GFNVo=; b=bcz09As+lVaCmt3o+HwI4No73oXR166lzmICYMLLTajMJTmIX2euPcJuNTQUUwum6f Bmce/59szQUQkZil43eutLMxAd/DqRCjp9cPnA9cjAC9h6UfVNUuH9Rkye+1ukGLqXEM z9cCdjSbLjFliuyVzUDNzBu8hf+GjGQVB0wXcsjhkesTvQI0UjtusE4TebXyO7Ito69D yyksqgEVYauGFVAuyJZ5xX2earhb9TTIhtay3QhzANfUG/1MtnXVGYewSS1on/Ao5k7U YRq/8GOPC0xh6XuVPoiXRumWaBDwizVGrHotHyJuxGQeywPNHeRBvk7GBvWi4ynUrdkQ 09PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ca5ZPRZf1cUMIZMMn1Uf8ybaj5g14R8F1QGbq1GFNVo=; b=HAE7PlDSkbjdJHNfwAOJ9UqbCVVZYYRW2KZUHE6eycgD7B3wROuyXVRs5dvubpr/wM lK2d8vbbYJogArhKiqnNLGt6unqoPtg//10HCqhv7VwdS/7VBdNIEOyaZoAk0CAn9WzW mNaYVZqo62trF212neE70bWYXd5hJMkYU+mN20z+pcGoN3iApCjx6ZFEXM4ryQtdXqPR TFND5vAlvaRVAJphL6pC5vOUMgzoJA6sLzOaG2aexhOEXNIGAwjuF7KpYW8z/oKtcqMn 0xaekle3lK/w48z638sMfIx0S3YtHasq/Rctx1w1ciP27SlctGD6fQjiaYNpmvp/ImpM 4MfQ== X-Gm-Message-State: AOPr4FWyP1TPeQb2U789OxrkEpFYh/kxepA9DGSy5S3xHQ9JzbHYyArrMtsyKpXtUGd6IQ== X-Received: by 10.194.90.229 with SMTP id bz5mr11258115wjb.143.1460561067765; Wed, 13 Apr 2016 08:24:27 -0700 (PDT) Received: from [192.168.0.9] (5ec0a29f.skybroadband.com. [94.192.162.159]) by smtp.gmail.com with ESMTPSA id l124sm1782602wmf.11.2016.04.13.08.24.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 08:24:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Wed, 13 Apr 2016 16:24:25 +0100 Message-Id: References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> To: "Lengyel, Tamas" X-Mailer: Apple Mail (2.2104) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============2521327380458857414==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============2521327380458857414== Content-Type: multipart/alternative; boundary="Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375" --Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tamas, apologies. I missed this in my inbox ... I made a few minor suggestions: mainly shortening some sentences.=20 There are also a couple of questions Do you want me to upload this to the blog (under your username)? Where = do you want to insert the png's? > On 25 Jan 2016, at 20:51, Lengyel, Tamas wrote: >=20 > Hi all, > here is an updated version. Also, a couple pictures that could be used = as illustrations. Feel free to punch it up as needed ;) >=20 > Tamas >=20 > Stealthy monitoring with Xen altp2m >=20 > One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer "In Xen 4.6 which was was released last autumn" > several new features have been introduced that make this subsystem = better; a cleaned-up, optimized API and ARM support being just some of = the biggest items on this list. As part of this release of Xen, a new = and unique feature was also successfully added by a team from Intel that = make stealthy monitoring even better on Xen: altp2m. In this blog entry = we will take a look at what it's all about. >=20 > In Xen's terminology, p2m stands for the memory management layer that = handles the translation from guest [p]hysical memory to [m]achine = physical. This translation is critical for safely partitioning the real = memory of machine between Xen and the various VMs running as to ensure a = VM can't simply access the memory of another. There are several = implementations of this There are several implementations of this mechanism, > including one with hardware support via Intel Extended Page Tables = (EPT) available to HVM (and PVH) guests and PVH . > , called Hardware Assisted Paging (hap) in Xen's terminology. In Xen's terminology, this is called Hardware Assisted Paging (hap). > In this implementation the hypervisor maintains a second pagetable, = similar to the one in 64-bit operating systems use, dedicated to running = the p2m translation. All (open-source) hypervisors that use this = hardware assisted paging method use a single EPT per virtual machine to = handle this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards. >=20 > Xen altp2m is the first implementation which changes this setup by = allowing Xen to create more then one EPT for each guest. Interestingly, = the Intel hardware has been capable of maintaining up to 512 EPT = pointers in the VMCS since the first introduction of EPT; however, noone = made use of this capability until now. This changed in Xen 4.6, where we = can now create of up to 10 EPTs per guest. The primary reason for this = extension is of course the new #VE and VMFUNC extensions that were = released in the Skylake generation of CPUs (which is worth a whole = blog-entry on its own), but it can also be used by external monitoring = applications via the Xen vm_event system. It can also be used by external monitoring applications via the Xen = vm_event system. Add a sub-headline: Why alt2pm is a game-changer >=20 > Why this feature is a game-changer for applications performing purely = external monitoring is because it simplifies the monitoring process of = multi-vCPU guests. Alt2pm is a game-changer for applications performing purely external = monitoring is because it simplifies the monitoring process of multi-vCPU = guests. > The EPT layer has been successfully used in stealthy monitoring = applications to track the memory accesses made by the VM from a safe = vantage point by restricting the type of access the VM may perform on = various memory pages. Since EPT permission violations trap into the = hypervisor, the VM would receive no indication that anything out of the = ordinary has happened. While the method allowed for stealthy tracing of = R/W/X memory accesses of the guest, the memory permission needs to be = relaxed in order to allow the guest to continue execution. When a single = EPT is shared across multiple running vCPUs, relaxing the permissions to = allow one vCPU to continue may inadvertantly allow another one to = perform the memory access we would otherwise want to track. While under = normal circumstances such race-condition may rarely occur, malicious = code could easily use this to hide some of its actions from a monitoring = application. >=20 > Solutions to this problem exist already. For example we can pause all = vCPUs while the one violating the access is singlestepped. This approach = however introduces heavy overhead just to avoid a race-condition that = may rarely occur in practice. Alternatively, one could emulate the = instruction that was violating the EPT permission without relaxing the = EPT access permissions, as Xen's built-in emulator doesn't use EPT to = access the guest memory. This solution, while supported in Xen, is not = particularly ideal either as Xen's emulator is incomplete and is known = to have issues that can lead to guest instability [2]. Furthermore, over = the years emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available. >=20 > Xen's altp2m system changes this problem quite significantly. By = having multiple EPTs we can have differing access permissions defined in = each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution. >=20 Add a sub-headline: Other introspection methods for stealthy monitoring > Of course, EPT based monitoring is not the only introspecting = technique used for stealthy monitoring. For example, the Xen based = DRAKVUF Dynamic Malware Analysis [4] uses it in combination with an = additional technique to maximum effect. > The main motivation for that is because EPT based monitoring is known = to introduce significant overhead, even with altp2m: the granularity of = the monitoring is that of a memory page (4KB). This sentence is a bit convoluted and I lost you here. Not quite sure = what you are trying to say > If the monitoring application is really just interested, for example, = when a function-entry point is called, EPT based monitoring creates a = lot of "false" events when that page is accessed for the rest of the = function's code. Again, something seems to be missing here and I am struggling to = understand what you are trying to say > Fortunately, this can be avoided by enabling the trapping of debug = instructions into the hypervisor, a built-in feature of Intel CPUs that = Xen exposes to third-party applications. This method is used in DRAKVUF, = which writes breakpoint instructions into the guests' memory at = code-locations of interest. Since we will only get an event for = precisely the code-location we are interested in this method effectively = reduces the overhead. However, the trade-off is that unlike EPT = permissions the breakpoints are now visible to the guest. Thus, to hide = the presence of the breakpoints from the guest, these pages need to get = further protected by restricting the pages to be execute-only in the = EPT. This allows DRAKVUF to remove the breakpoints before in-guest = code-integrity checking mechanisms (like Windows Patchguard) can access = the page. While with altp2m the EPT permissions can be safely used with = multi-vCPU systems, using breakpoints similarly presents a = race-condition: the breakpoint hit by one vCPU has to be removed to = allow the guest to execute the instruction that was originally = overwritten, potentially allowing another vCPU to do so as well without = notice. >=20 > Fortunately, altp2m has another neat feature that can be used to solve = this problem. Beside allowing for changing the memory permissions in the = different altp2m views, it also allows to change the mapping itself! The = same guest physical memory can be setup to be backed by different pages = in the different views. With this feature we can really thing of guest = physical assuming: thing=3Dthink > memory as "virtual": where it is mapped really depends on which view = the vCPU is running on. Using this feature allows us to hide the = presence of the breakpoints in a brand new way. To do this, first we = create a complete shadow copy of the memory page where a breakpoint is = going to be written and only write the breakpoint into this shadow copy. = Now, using altp2m, we setup a view where the guest physical memory of = the page gets mapped to our shadow copy. The guest continues to access = its physical memory as before, but underneath it is now using the = trapped shadow copy. When the breakpoint is hit, or if something is = trying to scan the code, we simply switch the view to the un-altered = view for the duration of a singlestep, then switch back to the trapped = view. This allows us to hide the presence of the breakpoints specific to = each vCPU! All without having pause any of the other vCPUs or having to = emulate. The first open-source implementation of this tracing has been = already merged into the DRAKVUF Malware Analysis System and is available = as a reference implementation for those interested in more details. >=20 > As we can see, Xen continues to be on the forefront of advancing the = development of virtualization based security application and allowing = third-party tools to create some very exotic setups. This flexibility is = what's so great about Xen and why it will continue to be a trend-setter = for the foreseeable future. >=20 Add a sub-headline: References > [1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection = > [2] http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.html = > [3] = https://blog.xenproject.org/2015/05/14/hardening-hypervisors-against-venom= -style-attacks/ = > [4] http://drakvuf.com > --Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tamas,

apologies. I missed this in my inbox ...

I made a few minor = suggestions: mainly shortening some sentences. 
There are also a couple of questions

Do you want me to upload this to the = blog (under your username)? Where do you want to insert the = png's?

On 25 Jan 2016, at 20:51, Lengyel, Tamas = <tlengyel@novetta.com> wrote:

Hi all,
here is an updated version. Also, a couple pictures that = could be used as illustrations. Feel free to punch it up as needed ;)

Tamas


Stealthy monitoring with Xen altp2m

One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer =

"In Xen 4.6 = which was was released last autumn"

several new features have been introduced that make this = subsystem better; a cleaned-up, optimized API and ARM support being just = some of the biggest items on this list. As part of this release of Xen, = a new and unique feature was also successfully added by a team from = Intel that make stealthy monitoring even better on Xen: altp2m. In this = blog entry we will take a look at what it's all about.

In Xen's terminology, p2m stands for the memory management = layer that handles the translation from guest [p]hysical memory to = [m]achine physical. This translation is critical for safely partitioning = the real memory of machine between Xen and the various VMs running as to = ensure a VM can't simply access the memory of another. There are several = implementations of this

There are several implementations of this mechanism,

including one = with hardware support via Intel Extended Page Tables (EPT) available to = HVM (and PVH) guests

and PVH <guests>.

, called Hardware Assisted Paging = (hap) in Xen's terminology.

In Xen's terminology, this is called Hardware = Assisted Paging (hap).

In = this implementation the hypervisor maintains a second pagetable, similar = to the one in 64-bit operating systems use, dedicated to running the p2m = translation. All (open-source) hypervisors that use this hardware = assisted paging method use a single EPT per virtual machine to handle = this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards.

Xen altp2m is the first implementation which = changes this setup by allowing Xen to create more then one EPT for each = guest. Interestingly, the Intel hardware has been capable of maintaining = up to 512 EPT pointers in the VMCS since the first introduction of EPT; = however, noone made use of this capability until now. This changed in = Xen 4.6, where we can now create of up to 10 EPTs per guest. The primary = reason for this extension is of course the new #VE and VMFUNC extensions = that were released in the Skylake generation of CPUs (which is worth a = whole blog-entry on its own), but it can also be used by external = monitoring applications via the Xen vm_event system.

It = can also be used by external monitoring applications via the Xen = vm_event system.

Add a sub-headline: = Why alt2pm is a game-changer


Why this feature is a game-changer for = applications performing purely external monitoring is because it = simplifies the monitoring process of multi-vCPU guests. =

Alt2pm is a = game-changer for applications performing purely external monitoring is = because it simplifies the monitoring process of multi-vCPU = guests.

The EPT layer = has been successfully used in stealthy monitoring applications to track = the memory accesses made by the VM from a safe vantage point by = restricting the type of access the VM may perform on various memory = pages. Since EPT permission violations trap into the hypervisor, the VM = would receive no indication that anything out of the ordinary has = happened. While the method allowed for stealthy tracing of R/W/X memory = accesses of the guest, the memory permission needs to be relaxed in = order to allow the guest to continue execution. When a single EPT is = shared across multiple running vCPUs, relaxing the permissions to allow = one vCPU to continue may inadvertantly allow another one to perform the = memory access we would otherwise want to track. While under normal = circumstances such race-condition may rarely occur, malicious code could = easily use this to hide some of its actions from a monitoring = application.

Solutions to this problem = exist already. For example we can pause all vCPUs while the one = violating the access is singlestepped. This approach however introduces = heavy overhead just to avoid a race-condition that may rarely occur in = practice. Alternatively, one could emulate the instruction that was = violating the EPT permission without relaxing the EPT access = permissions, as Xen's built-in emulator doesn't use EPT to access the = guest memory. This solution, while supported in Xen, is not particularly = ideal either as Xen's emulator is incomplete and is known to have issues = that can lead to guest instability [2]. Furthermore, over the years = emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available.

Xen's altp2m system changes this problem quite significantly. = By having multiple EPTs we can have differing access permissions defined = in each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution.


Add = a sub-headline: Other introspection methods for stealthy = monitoring

Of = course, EPT based monitoring is not the only introspecting technique = used for stealthy monitoring. For example, the Xen based DRAKVUF Dynamic = Malware Analysis [4] uses it in combination with an additional technique = to maximum effect.

The main motivation for that is = because EPT based monitoring is known to introduce significant overhead, = even with altp2m: the granularity of the monitoring is that of a memory = page (4KB).

This sentence is a bit convoluted and I lost you = here. Not quite sure what you are trying to say

If the monitoring application is = really just interested, for example, when a function-entry point is = called, EPT based monitoring creates a lot of "false" events when that = page is accessed for the rest of the function's code. =

Again, = something seems to be missing here and I am struggling to understand =  what you are trying to say

Fortunately, this can be avoided by enabling the trapping of = debug instructions into the hypervisor, a built-in feature of Intel CPUs = that Xen exposes to third-party applications. This method is used in = DRAKVUF, which writes breakpoint instructions into the guests' memory at = code-locations of interest. Since we will only get an event for = precisely the code-location we are interested in this method effectively = reduces the overhead. However, the trade-off is that unlike EPT = permissions the breakpoints are now visible to the guest. Thus, to hide = the presence of the breakpoints from the guest, these pages need to get = further protected by restricting the pages to be execute-only in the = EPT. This allows DRAKVUF to remove the breakpoints before in-guest = code-integrity checking mechanisms (like Windows Patchguard) can access = the page. While with altp2m the EPT permissions can be safely used with = multi-vCPU systems, using breakpoints similarly presents a = race-condition: the breakpoint hit by one vCPU has to be removed to = allow the guest to execute the instruction that was originally = overwritten, potentially allowing another vCPU to do so as well without = notice.

Fortunately, altp2m has another = neat feature that can be used to solve this problem. Beside allowing for = changing the memory permissions in the different altp2m views, it also = allows to change the mapping itself! The same guest physical memory can = be setup to be backed by different pages in the different views. With = this feature we can really thing of guest physical =

assuming: = thing=3Dthink

memory as  "virtual": where it is mapped really depends = on which view the vCPU is running on. Using this feature allows us to = hide the presence of the breakpoints in a brand new way. To do this, = first  we create a complete shadow copy of the memory page where a = breakpoint is going to be written and only write the breakpoint into = this shadow copy. Now, using altp2m, we setup a view where the guest = physical memory of the page gets mapped to our shadow copy. The guest = continues to access its physical memory as before, but underneath it is = now using the trapped shadow copy. When the breakpoint is hit, or if = something is trying to scan the code, we simply switch the view to the = un-altered view for the duration of a singlestep, then switch back to = the trapped view. This allows us to hide the presence of the breakpoints = specific to each vCPU! All without having pause any of the other vCPUs = or having to emulate. The first open-source implementation of this = tracing has been already merged into the DRAKVUF Malware Analysis System = and is available as a reference implementation for those interested in = more details.

As we can see, Xen continues = to be on the forefront of advancing the development of virtualization = based security application and allowing third-party tools to create some = very exotic setups. This flexibility is what's so great about Xen and = why it will continue to be a trend-setter for the foreseeable future.


Add a sub-headline: References


= --Apple-Mail=_C7D0AE29-CF41-40AE-8F44-08D144706375-- --===============2521327380458857414== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============2521327380458857414==-- From publicity-bounces@lists.xenproject.org Wed Apr 13 15:59:53 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 15:59:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNCr-0002nZ-Mu; Wed, 13 Apr 2016 15:59:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNCp-0002nT-OA for publicity@lists.xenproject.org; Wed, 13 Apr 2016 15:59:52 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 30/0A-30904-6FC6E075; Wed, 13 Apr 2016 15:59:50 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleJIrShJLcpLzFFi42Lxqg0y1v2awxd ucPAer8XvvrWMDowehz9cYQlgjGLNzEvKr0hgzfj46hNTwb47jBV/ri9ibWBct4exi5GLQ0hg JqNE0717rCAOi0ADq8T/n8/BHAmBOawS/77cBHI4gZwYiWUrt0PZlRJbr3wDs4UE1CXuLbrND jHqG6PEsuP7GUESzAIJErM3fGIDsXkF9CRe3boM1iAsYCNx7OQ9MJtNQFti040HzCA2p4CtxN JnH8DiLAKqEvtPzWaHmBMgsbJ9FhPEHBuJJUeaWSCW7WWRWD/jFQtIQkRAX2JOZwMTxHWyErt /P2KawCg0C8kds5DcARHXlli28DUzjH390gVGTHEtifczL7EvYGRbxahRnFpUllqka2iql1SU mZ5RkpuYmaNraGCql5taXJyYnpqTmFSsl5yfu4kRGCMMQLCDsWG75yFGSQ4mJVHebcF84UJ8S fkplRmJxRnxRaU5qcWHGGU4OJQkeGuAMSckWJSanlqRlpkDjFaYtAQHj5IIrzBImre4IDG3OD MdInWKUZdjy9R7a5mEWPLy81KlxHkDQIoEQIoySvPgRsASxyVGWSlhXkago4R4ClKLcjNLUOV fMYpzMCoJ80aATOHJzCuB2/QK6AgmoCPK3vGCHFGSiJCSamBcEnjix+PQsuT17M4TZrittJyS O8+Z+c46388cwrI8bzv2TZV7teXZI63OzXNs7BuDYmYfrjxxopTj3qStze93/8vZK1jxY/Zsm ePnkmYsX+h55pqHzN7MxeE/npy+oGPYlVHNr3CY1YPFrDlNrP580NVXD/dYdRf/aeS7ePib6N ObWYHumz6FKLEUZyQaajEXFScCACIs5TsXAwAA X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1460563189!34280582!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16624 invoked from network); 13 Apr 2016 15:59:49 -0000 Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by server-6.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 15:59:49 -0000 Received: by mail-wm0-f51.google.com with SMTP id u206so86554767wme.1 for ; Wed, 13 Apr 2016 08:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Gb3IxyERnTSCYEV9fjPW8e75Icm0DIEpQ1nIRVly+Qk=; b=jYZebjx9fsMzmoLpjqLzsTlZ4xKilPF1G+SGlrXjDFNVIgqWgU+qW42xcOoo7jYr+P Cf5PeoNzh6n1brvvH6zkGDXHETvjfNewuQo0VXF9oLroeT6Aj6jcfLaw0zz0nOrPy2Of ohK4xGon4IfDmTi7YCRzvhsj6IueCmjaVWhhaYIhgkp3SRlWIQLJjb4SUsu+xozdVRCq SHkab3eOZBzGV+vYFVir/QphEHXB6iLkvCUSOPbTsv0Eru/vlxg5cmka0jqN6PnmNwDl iDnoLuW8K8gYBkjMlOZmNg+hwH4x8Vax3CiicFtCbIve/m4Nv+gM0EcIlKHV1UwDxBiF Q1Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Gb3IxyERnTSCYEV9fjPW8e75Icm0DIEpQ1nIRVly+Qk=; b=k+kS8fbkojFLInU0kpD/0qaJc1ADGH2MagmmuxlgD5dtWsnELNfelWn2bPqaXy0Ush VN1FggZfnaxO8rJqjgzXxNpVB9sWQO706SoRBmOoP29QBVBTVNav5nrvXRZLR3111Nmq +M2xbT3vaQH1BHMvimxbxk2mjbSz+RPK43B3+fiyKA+yiqN6o7CmBxu+rCcyJOzRU6B0 P8n/sPe2RsAaI4tAI+VQUb4Ht5LujsKVSuy6vRKq33Ufr8r7cm3zzoXghKCFWZC5weLz dUYhgZEwB6ntY2GJ6NaukZHvI/viJfnjkjbtzj2mycDruzORIBGTXYEizXZVHP2sI7Yh tIng== X-Gm-Message-State: AOPr4FVu3SVf8mwxpHoetui1hi9aq2R+WtNgt6s31k2HyzmF0Wh6abtLGdSRBuSoqx18oQ== X-Received: by 10.28.167.16 with SMTP id q16mr14100714wme.85.1460563188890; Wed, 13 Apr 2016 08:59:48 -0700 (PDT) Received: from [192.168.0.12] (5ec0a29f.skybroadband.com. [94.192.162.159]) by smtp.gmail.com with ESMTPSA id j71sm1910948wmj.21.2016.04.13.08.59.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 08:59:46 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Wed, 13 Apr 2016 16:59:46 +0100 Message-Id: <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> To: Tamas K Lengyel X-Mailer: Apple Mail (2.2104) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============8126900994177111711==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============8126900994177111711== Content-Type: multipart/alternative; boundary="Apple-Mail=_50884264-0431-45DD-BFE5-121396905568" --Apple-Mail=_50884264-0431-45DD-BFE5-121396905568 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Draft blog at https://blog.xenproject.org/?p=3D11282&preview=3Dtrue = @Tamas Please do a quick sanity check and let me know whether to publish. I = also updated your bio: if you want extra mods, let me know Your account is linked to the above email address: you may want to reset = the password Lars > On 13 Apr 2016, at 16:24, Lars Kurth wrote: >=20 > Tamas, >=20 > apologies. I missed this in my inbox ... >=20 > I made a few minor suggestions: mainly shortening some sentences.=20 > There are also a couple of questions >=20 > Do you want me to upload this to the blog (under your username)? Where = do you want to insert the png's? >=20 >> On 25 Jan 2016, at 20:51, Lengyel, Tamas > wrote: >>=20 >> Hi all, >> here is an updated version. Also, a couple pictures that could be = used as illustrations. Feel free to punch it up as needed ;) >>=20 >> Tamas >>=20 >=20 >> Stealthy monitoring with Xen altp2m >>=20 >> One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer >=20 > "In Xen 4.6 which was was released last autumn" >=20 >> several new features have been introduced that make this subsystem = better; a cleaned-up, optimized API and ARM support being just some of = the biggest items on this list. As part of this release of Xen, a new = and unique feature was also successfully added by a team from Intel that = make stealthy monitoring even better on Xen: altp2m. In this blog entry = we will take a look at what it's all about. >>=20 >> In Xen's terminology, p2m stands for the memory management layer that = handles the translation from guest [p]hysical memory to [m]achine = physical. This translation is critical for safely partitioning the real = memory of machine between Xen and the various VMs running as to ensure a = VM can't simply access the memory of another. There are several = implementations of this >=20 > There are several implementations of this mechanism, >=20 >> including one with hardware support via Intel Extended Page Tables = (EPT) available to HVM (and PVH) guests >=20 > and PVH . >=20 >> , called Hardware Assisted Paging (hap) in Xen's terminology. >=20 > In Xen's terminology, this is called Hardware Assisted Paging (hap). >=20 >> In this implementation the hypervisor maintains a second pagetable, = similar to the one in 64-bit operating systems use, dedicated to running = the p2m translation. All (open-source) hypervisors that use this = hardware assisted paging method use a single EPT per virtual machine to = handle this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards. >>=20 >> Xen altp2m is the first implementation which changes this setup by = allowing Xen to create more then one EPT for each guest. Interestingly, = the Intel hardware has been capable of maintaining up to 512 EPT = pointers in the VMCS since the first introduction of EPT; however, noone = made use of this capability until now. This changed in Xen 4.6, where we = can now create of up to 10 EPTs per guest. The primary reason for this = extension is of course the new #VE and VMFUNC extensions that were = released in the Skylake generation of CPUs (which is worth a whole = blog-entry on its own), but it can also be used by external monitoring = applications via the Xen vm_event system. >=20 > It can also be used by external monitoring applications via the Xen = vm_event system. >=20 > Add a sub-headline: Why alt2pm is a game-changer >=20 >>=20 >> Why this feature is a game-changer for applications performing purely = external monitoring is because it simplifies the monitoring process of = multi-vCPU guests. >=20 > Alt2pm is a game-changer for applications performing purely external = monitoring is because it simplifies the monitoring process of multi-vCPU = guests. >=20 >> The EPT layer has been successfully used in stealthy monitoring = applications to track the memory accesses made by the VM from a safe = vantage point by restricting the type of access the VM may perform on = various memory pages. Since EPT permission violations trap into the = hypervisor, the VM would receive no indication that anything out of the = ordinary has happened. While the method allowed for stealthy tracing of = R/W/X memory accesses of the guest, the memory permission needs to be = relaxed in order to allow the guest to continue execution. When a single = EPT is shared across multiple running vCPUs, relaxing the permissions to = allow one vCPU to continue may inadvertantly allow another one to = perform the memory access we would otherwise want to track. While under = normal circumstances such race-condition may rarely occur, malicious = code could easily use this to hide some of its actions from a monitoring = application. >>=20 >> Solutions to this problem exist already. For example we can pause all = vCPUs while the one violating the access is singlestepped. This approach = however introduces heavy overhead just to avoid a race-condition that = may rarely occur in practice. Alternatively, one could emulate the = instruction that was violating the EPT permission without relaxing the = EPT access permissions, as Xen's built-in emulator doesn't use EPT to = access the guest memory. This solution, while supported in Xen, is not = particularly ideal either as Xen's emulator is incomplete and is known = to have issues that can lead to guest instability [2]. Furthermore, over = the years emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available. >>=20 >> Xen's altp2m system changes this problem quite significantly. By = having multiple EPTs we can have differing access permissions defined in = each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution. >>=20 >=20 > Add a sub-headline: Other introspection methods for stealthy = monitoring >=20 >> Of course, EPT based monitoring is not the only introspecting = technique used for stealthy monitoring. For example, the Xen based = DRAKVUF Dynamic Malware Analysis [4] uses it in combination with an = additional technique to maximum effect. >=20 >> The main motivation for that is because EPT based monitoring is known = to introduce significant overhead, even with altp2m: the granularity of = the monitoring is that of a memory page (4KB). >=20 > This sentence is a bit convoluted and I lost you here. Not quite sure = what you are trying to say >=20 >> If the monitoring application is really just interested, for example, = when a function-entry point is called, EPT based monitoring creates a = lot of "false" events when that page is accessed for the rest of the = function's code. >=20 > Again, something seems to be missing here and I am struggling to = understand what you are trying to say >=20 >> Fortunately, this can be avoided by enabling the trapping of debug = instructions into the hypervisor, a built-in feature of Intel CPUs that = Xen exposes to third-party applications. This method is used in DRAKVUF, = which writes breakpoint instructions into the guests' memory at = code-locations of interest. Since we will only get an event for = precisely the code-location we are interested in this method effectively = reduces the overhead. However, the trade-off is that unlike EPT = permissions the breakpoints are now visible to the guest. Thus, to hide = the presence of the breakpoints from the guest, these pages need to get = further protected by restricting the pages to be execute-only in the = EPT. This allows DRAKVUF to remove the breakpoints before in-guest = code-integrity checking mechanisms (like Windows Patchguard) can access = the page. While with altp2m the EPT permissions can be safely used with = multi-vCPU systems, using breakpoints similarly presents a = race-condition: the breakpoint hit by one vCPU has to be removed to = allow the guest to execute the instruction that was originally = overwritten, potentially allowing another vCPU to do so as well without = notice. >>=20 >> Fortunately, altp2m has another neat feature that can be used to = solve this problem. Beside allowing for changing the memory permissions = in the different altp2m views, it also allows to change the mapping = itself! The same guest physical memory can be setup to be backed by = different pages in the different views. With this feature we can really = thing of guest physical >=20 > assuming: thing=3Dthink >=20 >> memory as "virtual": where it is mapped really depends on which view = the vCPU is running on. Using this feature allows us to hide the = presence of the breakpoints in a brand new way. To do this, first we = create a complete shadow copy of the memory page where a breakpoint is = going to be written and only write the breakpoint into this shadow copy. = Now, using altp2m, we setup a view where the guest physical memory of = the page gets mapped to our shadow copy. The guest continues to access = its physical memory as before, but underneath it is now using the = trapped shadow copy. When the breakpoint is hit, or if something is = trying to scan the code, we simply switch the view to the un-altered = view for the duration of a singlestep, then switch back to the trapped = view. This allows us to hide the presence of the breakpoints specific to = each vCPU! All without having pause any of the other vCPUs or having to = emulate. The first open-source implementation of this tracing has been = already merged into the DRAKVUF Malware Analysis System and is available = as a reference implementation for those interested in more details. >>=20 >> As we can see, Xen continues to be on the forefront of advancing the = development of virtualization based security application and allowing = third-party tools to create some very exotic setups. This flexibility is = what's so great about Xen and why it will continue to be a trend-setter = for the foreseeable future. >>=20 >=20 > Add a sub-headline: References >=20 >> [1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection = >> [2] = http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.html = >> [3] = https://blog.xenproject.org/2015/05/14/hardening-hypervisors-against-venom= -style-attacks/ = >> [4] http://drakvuf.com >> >=20 --Apple-Mail=_50884264-0431-45DD-BFE5-121396905568 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Draft blog at https://blog.xenproject.org/?p=3D11282&preview=3Dtrue
@Tamas
Please do a quick sanity check and let me know whether to = publish. I also updated your bio: if you want extra mods, let me = know
Your account is linked to the above email = address: you may want to reset the password

Lars

On = 13 Apr 2016, at 16:24, Lars Kurth <lars.kurth.xen@gmail.com> wrote:

Tamas,

apologies. I missed this = in my inbox ...

I made a few minor suggestions: mainly shortening some = sentences. 
There are also a couple of = questions

Do = you want me to upload this to the blog (under your username)? Where do = you want to insert the png's?

On 25 = Jan 2016, at 20:51, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi all,
here is an updated version. Also, a couple pictures that = could be used as illustrations. Feel free to punch it up as needed ;)

Tamas


Stealthy monitoring with Xen altp2m

One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer =

"In = Xen 4.6 which was was released last autumn"

several new features have been = introduced that make this subsystem better; a cleaned-up, optimized API = and ARM support being just some of the biggest items on this list. As = part of this release of Xen, a new and unique feature was also = successfully added by a team from Intel that make stealthy monitoring = even better on Xen: altp2m. In this blog entry we will take a look at = what it's all about.

In Xen's terminology, = p2m stands for the memory management layer that handles the translation = from guest [p]hysical memory to [m]achine physical. This translation is = critical for safely partitioning the real memory of machine between Xen = and the various VMs running as to ensure a VM can't simply access the = memory of another. There are several implementations of = this

There are several implementations of this mechanism,

including one = with hardware support via Intel Extended Page Tables (EPT) available to = HVM (and PVH) guests

and PVH <guests>.

, called Hardware = Assisted Paging (hap) in Xen's terminology. =

In Xen's terminology, this is called Hardware Assisted Paging = (hap).

In this = implementation the hypervisor maintains a second pagetable, similar to = the one in 64-bit operating systems use, dedicated to running the p2m = translation. All (open-source) hypervisors that use this hardware = assisted paging method use a single EPT per virtual machine to handle = this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards.

Xen altp2m is the first implementation which = changes this setup by allowing Xen to create more then one EPT for each = guest. Interestingly, the Intel hardware has been capable of maintaining = up to 512 EPT pointers in the VMCS since the first introduction of EPT; = however, noone made use of this capability until now. This changed in = Xen 4.6, where we can now create of up to 10 EPTs per guest. The primary = reason for this extension is of course the new #VE and VMFUNC extensions = that were released in the Skylake generation of CPUs (which is worth a = whole blog-entry on its own), but it can also be used by external = monitoring applications via the Xen vm_event system.

It can also be used by external monitoring applications = via the Xen vm_event system.

Add a sub-headline: Why alt2pm is a = game-changer


Why this feature is a game-changer for = applications performing purely external monitoring is because it = simplifies the monitoring process of multi-vCPU guests. =

Alt2pm= is a game-changer for applications performing purely external = monitoring is because it simplifies the monitoring process of multi-vCPU = guests.

The= EPT layer has been successfully used in stealthy monitoring = applications to track the memory accesses made by the VM from a safe = vantage point by restricting the type of access the VM may perform on = various memory pages. Since EPT permission violations trap into the = hypervisor, the VM would receive no indication that anything out of the = ordinary has happened. While the method allowed for stealthy tracing of = R/W/X memory accesses of the guest, the memory permission needs to be = relaxed in order to allow the guest to continue execution. When a single = EPT is shared across multiple running vCPUs, relaxing the permissions to = allow one vCPU to continue may inadvertantly allow another one to = perform the memory access we would otherwise want to track. While under = normal circumstances such race-condition may rarely occur, malicious = code could easily use this to hide some of its actions from a monitoring = application.

Solutions to this problem = exist already. For example we can pause all vCPUs while the one = violating the access is singlestepped. This approach however introduces = heavy overhead just to avoid a race-condition that may rarely occur in = practice. Alternatively, one could emulate the instruction that was = violating the EPT permission without relaxing the EPT access = permissions, as Xen's built-in emulator doesn't use EPT to access the = guest memory. This solution, while supported in Xen, is not particularly = ideal either as Xen's emulator is incomplete and is known to have issues = that can lead to guest instability [2]. Furthermore, over the years = emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available.

Xen's altp2m system changes this problem quite significantly. = By having multiple EPTs we can have differing access permissions defined = in each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution.


Add a sub-headline: Other introspection methods for = stealthy monitoring

Of course, EPT based monitoring is not the only introspecting = technique used for stealthy monitoring. For example, the Xen based = DRAKVUF Dynamic Malware Analysis [4] uses it in combination with an = additional technique to maximum effect. =

The= main motivation for that is because EPT based monitoring is known to = introduce significant overhead, even with altp2m: the granularity of the = monitoring is that of a memory page = (4KB).

This sentence is a bit convoluted and I = lost you here. Not quite sure what you are trying to say

If the monitoring application is = really just interested, for example, when a function-entry point is = called, EPT based monitoring creates a lot of "false" events when that = page is accessed for the rest of the function's code. =

Again,= something seems to be missing here and I am struggling to understand =  what you are trying to say

Fortunately, this can be avoided = by enabling the trapping of debug instructions into the hypervisor, a = built-in feature of Intel CPUs that Xen exposes to third-party = applications. This method is used in DRAKVUF, which writes breakpoint = instructions into the guests' memory at code-locations of interest. = Since we will only get an event for precisely the code-location we are = interested in this method effectively reduces the overhead. However, the = trade-off is that unlike EPT permissions the breakpoints are now visible = to the guest. Thus, to hide the presence of the breakpoints from the = guest, these pages need to get further protected by restricting the = pages to be execute-only in the EPT. This allows DRAKVUF to remove the = breakpoints before in-guest code-integrity checking mechanisms (like = Windows Patchguard) can access the page. While with altp2m the EPT = permissions can be safely used with multi-vCPU systems, using = breakpoints similarly presents a race-condition: the breakpoint hit by = one vCPU has to be removed to allow the guest to execute the instruction = that was originally overwritten, potentially allowing another vCPU to do = so as well without notice.

Fortunately, = altp2m has another neat feature that can be used to solve this problem. = Beside allowing for changing the memory permissions in the different = altp2m views, it also allows to change the mapping itself! The same = guest physical memory can be setup to be backed by different pages in = the different views. With this feature we can really thing of guest = physical

assuming: thing=3Dthink

memory as  "virtual": where = it is mapped really depends on which view the vCPU is running on. Using = this feature allows us to hide the presence of the breakpoints in a = brand new way. To do this, first  we create a complete shadow copy = of the memory page where a breakpoint is going to be written and only = write the breakpoint into this shadow copy. Now, using altp2m, we setup = a view where the guest physical memory of the page gets mapped to our = shadow copy. The guest continues to access its physical memory as = before, but underneath it is now using the trapped shadow copy. When the = breakpoint is hit, or if something is trying to scan the code, we simply = switch the view to the un-altered view for the duration of a singlestep, = then switch back to the trapped view. This allows us to hide the = presence of the breakpoints specific to each vCPU! All without having = pause any of the other vCPUs or having to emulate. The first open-source = implementation of this tracing has been already merged into the DRAKVUF = Malware Analysis System and is available as a reference implementation = for those interested in more details.

As we = can see, Xen continues to be on the forefront of advancing the = development of virtualization based security application and allowing = third-party tools to create some very exotic setups. This flexibility is = what's so great about Xen and why it will continue to be a trend-setter = for the foreseeable future.


Add a sub-headline: References

[1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection
[2] http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.h= tml
[3] https://blog.xenproject.org/2015/05/14/hardening-hypervisors-ag= ainst-venom-style-attacks/
[4] http://drakvuf.com
<altp2m.png><altp2m-shadow.png><p2m.png>


= --Apple-Mail=_50884264-0431-45DD-BFE5-121396905568-- --===============8126900994177111711== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============8126900994177111711==-- From publicity-bounces@lists.xenproject.org Wed Apr 13 15:59:53 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 15:59:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNCr-0002nZ-Mu; Wed, 13 Apr 2016 15:59:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNCp-0002nT-OA for publicity@lists.xenproject.org; Wed, 13 Apr 2016 15:59:52 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 30/0A-30904-6FC6E075; Wed, 13 Apr 2016 15:59:50 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleJIrShJLcpLzFFi42Lxqg0y1v2awxd ucPAer8XvvrWMDowehz9cYQlgjGLNzEvKr0hgzfj46hNTwb47jBV/ri9ibWBct4exi5GLQ0hg JqNE0717rCAOi0ADq8T/n8/BHAmBOawS/77cBHI4gZwYiWUrt0PZlRJbr3wDs4UE1CXuLbrND jHqG6PEsuP7GUESzAIJErM3fGIDsXkF9CRe3boM1iAsYCNx7OQ9MJtNQFti040HzCA2p4CtxN JnH8DiLAKqEvtPzWaHmBMgsbJ9FhPEHBuJJUeaWSCW7WWRWD/jFQtIQkRAX2JOZwMTxHWyErt /P2KawCg0C8kds5DcARHXlli28DUzjH390gVGTHEtifczL7EvYGRbxahRnFpUllqka2iql1SU mZ5RkpuYmaNraGCql5taXJyYnpqTmFSsl5yfu4kRGCMMQLCDsWG75yFGSQ4mJVHebcF84UJ8S fkplRmJxRnxRaU5qcWHGGU4OJQkeGuAMSckWJSanlqRlpkDjFaYtAQHj5IIrzBImre4IDG3OD MdInWKUZdjy9R7a5mEWPLy81KlxHkDQIoEQIoySvPgRsASxyVGWSlhXkago4R4ClKLcjNLUOV fMYpzMCoJ80aATOHJzCuB2/QK6AgmoCPK3vGCHFGSiJCSamBcEnjix+PQsuT17M4TZrittJyS O8+Z+c46388cwrI8bzv2TZV7teXZI63OzXNs7BuDYmYfrjxxopTj3qStze93/8vZK1jxY/Zsm ePnkmYsX+h55pqHzN7MxeE/npy+oGPYlVHNr3CY1YPFrDlNrP580NVXD/dYdRf/aeS7ePib6N ObWYHumz6FKLEUZyQaajEXFScCACIs5TsXAwAA X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1460563189!34280582!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16624 invoked from network); 13 Apr 2016 15:59:49 -0000 Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by server-6.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 15:59:49 -0000 Received: by mail-wm0-f51.google.com with SMTP id u206so86554767wme.1 for ; Wed, 13 Apr 2016 08:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Gb3IxyERnTSCYEV9fjPW8e75Icm0DIEpQ1nIRVly+Qk=; b=jYZebjx9fsMzmoLpjqLzsTlZ4xKilPF1G+SGlrXjDFNVIgqWgU+qW42xcOoo7jYr+P Cf5PeoNzh6n1brvvH6zkGDXHETvjfNewuQo0VXF9oLroeT6Aj6jcfLaw0zz0nOrPy2Of ohK4xGon4IfDmTi7YCRzvhsj6IueCmjaVWhhaYIhgkp3SRlWIQLJjb4SUsu+xozdVRCq SHkab3eOZBzGV+vYFVir/QphEHXB6iLkvCUSOPbTsv0Eru/vlxg5cmka0jqN6PnmNwDl iDnoLuW8K8gYBkjMlOZmNg+hwH4x8Vax3CiicFtCbIve/m4Nv+gM0EcIlKHV1UwDxBiF Q1Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Gb3IxyERnTSCYEV9fjPW8e75Icm0DIEpQ1nIRVly+Qk=; b=k+kS8fbkojFLInU0kpD/0qaJc1ADGH2MagmmuxlgD5dtWsnELNfelWn2bPqaXy0Ush VN1FggZfnaxO8rJqjgzXxNpVB9sWQO706SoRBmOoP29QBVBTVNav5nrvXRZLR3111Nmq +M2xbT3vaQH1BHMvimxbxk2mjbSz+RPK43B3+fiyKA+yiqN6o7CmBxu+rCcyJOzRU6B0 P8n/sPe2RsAaI4tAI+VQUb4Ht5LujsKVSuy6vRKq33Ufr8r7cm3zzoXghKCFWZC5weLz dUYhgZEwB6ntY2GJ6NaukZHvI/viJfnjkjbtzj2mycDruzORIBGTXYEizXZVHP2sI7Yh tIng== X-Gm-Message-State: AOPr4FVu3SVf8mwxpHoetui1hi9aq2R+WtNgt6s31k2HyzmF0Wh6abtLGdSRBuSoqx18oQ== X-Received: by 10.28.167.16 with SMTP id q16mr14100714wme.85.1460563188890; Wed, 13 Apr 2016 08:59:48 -0700 (PDT) Received: from [192.168.0.12] (5ec0a29f.skybroadband.com. [94.192.162.159]) by smtp.gmail.com with ESMTPSA id j71sm1910948wmj.21.2016.04.13.08.59.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 08:59:46 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Wed, 13 Apr 2016 16:59:46 +0100 Message-Id: <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> To: Tamas K Lengyel X-Mailer: Apple Mail (2.2104) Cc: publicity@lists.xenproject.org Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============8126900994177111711==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============8126900994177111711== Content-Type: multipart/alternative; boundary="Apple-Mail=_50884264-0431-45DD-BFE5-121396905568" --Apple-Mail=_50884264-0431-45DD-BFE5-121396905568 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Draft blog at https://blog.xenproject.org/?p=3D11282&preview=3Dtrue = @Tamas Please do a quick sanity check and let me know whether to publish. I = also updated your bio: if you want extra mods, let me know Your account is linked to the above email address: you may want to reset = the password Lars > On 13 Apr 2016, at 16:24, Lars Kurth wrote: >=20 > Tamas, >=20 > apologies. I missed this in my inbox ... >=20 > I made a few minor suggestions: mainly shortening some sentences.=20 > There are also a couple of questions >=20 > Do you want me to upload this to the blog (under your username)? Where = do you want to insert the png's? >=20 >> On 25 Jan 2016, at 20:51, Lengyel, Tamas > wrote: >>=20 >> Hi all, >> here is an updated version. Also, a couple pictures that could be = used as illustrations. Feel free to punch it up as needed ;) >>=20 >> Tamas >>=20 >=20 >> Stealthy monitoring with Xen altp2m >>=20 >> One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer >=20 > "In Xen 4.6 which was was released last autumn" >=20 >> several new features have been introduced that make this subsystem = better; a cleaned-up, optimized API and ARM support being just some of = the biggest items on this list. As part of this release of Xen, a new = and unique feature was also successfully added by a team from Intel that = make stealthy monitoring even better on Xen: altp2m. In this blog entry = we will take a look at what it's all about. >>=20 >> In Xen's terminology, p2m stands for the memory management layer that = handles the translation from guest [p]hysical memory to [m]achine = physical. This translation is critical for safely partitioning the real = memory of machine between Xen and the various VMs running as to ensure a = VM can't simply access the memory of another. There are several = implementations of this >=20 > There are several implementations of this mechanism, >=20 >> including one with hardware support via Intel Extended Page Tables = (EPT) available to HVM (and PVH) guests >=20 > and PVH . >=20 >> , called Hardware Assisted Paging (hap) in Xen's terminology. >=20 > In Xen's terminology, this is called Hardware Assisted Paging (hap). >=20 >> In this implementation the hypervisor maintains a second pagetable, = similar to the one in 64-bit operating systems use, dedicated to running = the p2m translation. All (open-source) hypervisors that use this = hardware assisted paging method use a single EPT per virtual machine to = handle this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards. >>=20 >> Xen altp2m is the first implementation which changes this setup by = allowing Xen to create more then one EPT for each guest. Interestingly, = the Intel hardware has been capable of maintaining up to 512 EPT = pointers in the VMCS since the first introduction of EPT; however, noone = made use of this capability until now. This changed in Xen 4.6, where we = can now create of up to 10 EPTs per guest. The primary reason for this = extension is of course the new #VE and VMFUNC extensions that were = released in the Skylake generation of CPUs (which is worth a whole = blog-entry on its own), but it can also be used by external monitoring = applications via the Xen vm_event system. >=20 > It can also be used by external monitoring applications via the Xen = vm_event system. >=20 > Add a sub-headline: Why alt2pm is a game-changer >=20 >>=20 >> Why this feature is a game-changer for applications performing purely = external monitoring is because it simplifies the monitoring process of = multi-vCPU guests. >=20 > Alt2pm is a game-changer for applications performing purely external = monitoring is because it simplifies the monitoring process of multi-vCPU = guests. >=20 >> The EPT layer has been successfully used in stealthy monitoring = applications to track the memory accesses made by the VM from a safe = vantage point by restricting the type of access the VM may perform on = various memory pages. Since EPT permission violations trap into the = hypervisor, the VM would receive no indication that anything out of the = ordinary has happened. While the method allowed for stealthy tracing of = R/W/X memory accesses of the guest, the memory permission needs to be = relaxed in order to allow the guest to continue execution. When a single = EPT is shared across multiple running vCPUs, relaxing the permissions to = allow one vCPU to continue may inadvertantly allow another one to = perform the memory access we would otherwise want to track. While under = normal circumstances such race-condition may rarely occur, malicious = code could easily use this to hide some of its actions from a monitoring = application. >>=20 >> Solutions to this problem exist already. For example we can pause all = vCPUs while the one violating the access is singlestepped. This approach = however introduces heavy overhead just to avoid a race-condition that = may rarely occur in practice. Alternatively, one could emulate the = instruction that was violating the EPT permission without relaxing the = EPT access permissions, as Xen's built-in emulator doesn't use EPT to = access the guest memory. This solution, while supported in Xen, is not = particularly ideal either as Xen's emulator is incomplete and is known = to have issues that can lead to guest instability [2]. Furthermore, over = the years emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available. >>=20 >> Xen's altp2m system changes this problem quite significantly. By = having multiple EPTs we can have differing access permissions defined in = each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution. >>=20 >=20 > Add a sub-headline: Other introspection methods for stealthy = monitoring >=20 >> Of course, EPT based monitoring is not the only introspecting = technique used for stealthy monitoring. For example, the Xen based = DRAKVUF Dynamic Malware Analysis [4] uses it in combination with an = additional technique to maximum effect. >=20 >> The main motivation for that is because EPT based monitoring is known = to introduce significant overhead, even with altp2m: the granularity of = the monitoring is that of a memory page (4KB). >=20 > This sentence is a bit convoluted and I lost you here. Not quite sure = what you are trying to say >=20 >> If the monitoring application is really just interested, for example, = when a function-entry point is called, EPT based monitoring creates a = lot of "false" events when that page is accessed for the rest of the = function's code. >=20 > Again, something seems to be missing here and I am struggling to = understand what you are trying to say >=20 >> Fortunately, this can be avoided by enabling the trapping of debug = instructions into the hypervisor, a built-in feature of Intel CPUs that = Xen exposes to third-party applications. This method is used in DRAKVUF, = which writes breakpoint instructions into the guests' memory at = code-locations of interest. Since we will only get an event for = precisely the code-location we are interested in this method effectively = reduces the overhead. However, the trade-off is that unlike EPT = permissions the breakpoints are now visible to the guest. Thus, to hide = the presence of the breakpoints from the guest, these pages need to get = further protected by restricting the pages to be execute-only in the = EPT. This allows DRAKVUF to remove the breakpoints before in-guest = code-integrity checking mechanisms (like Windows Patchguard) can access = the page. While with altp2m the EPT permissions can be safely used with = multi-vCPU systems, using breakpoints similarly presents a = race-condition: the breakpoint hit by one vCPU has to be removed to = allow the guest to execute the instruction that was originally = overwritten, potentially allowing another vCPU to do so as well without = notice. >>=20 >> Fortunately, altp2m has another neat feature that can be used to = solve this problem. Beside allowing for changing the memory permissions = in the different altp2m views, it also allows to change the mapping = itself! The same guest physical memory can be setup to be backed by = different pages in the different views. With this feature we can really = thing of guest physical >=20 > assuming: thing=3Dthink >=20 >> memory as "virtual": where it is mapped really depends on which view = the vCPU is running on. Using this feature allows us to hide the = presence of the breakpoints in a brand new way. To do this, first we = create a complete shadow copy of the memory page where a breakpoint is = going to be written and only write the breakpoint into this shadow copy. = Now, using altp2m, we setup a view where the guest physical memory of = the page gets mapped to our shadow copy. The guest continues to access = its physical memory as before, but underneath it is now using the = trapped shadow copy. When the breakpoint is hit, or if something is = trying to scan the code, we simply switch the view to the un-altered = view for the duration of a singlestep, then switch back to the trapped = view. This allows us to hide the presence of the breakpoints specific to = each vCPU! All without having pause any of the other vCPUs or having to = emulate. The first open-source implementation of this tracing has been = already merged into the DRAKVUF Malware Analysis System and is available = as a reference implementation for those interested in more details. >>=20 >> As we can see, Xen continues to be on the forefront of advancing the = development of virtualization based security application and allowing = third-party tools to create some very exotic setups. This flexibility is = what's so great about Xen and why it will continue to be a trend-setter = for the foreseeable future. >>=20 >=20 > Add a sub-headline: References >=20 >> [1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection = >> [2] = http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.html = >> [3] = https://blog.xenproject.org/2015/05/14/hardening-hypervisors-against-venom= -style-attacks/ = >> [4] http://drakvuf.com >> >=20 --Apple-Mail=_50884264-0431-45DD-BFE5-121396905568 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Draft blog at https://blog.xenproject.org/?p=3D11282&preview=3Dtrue
@Tamas
Please do a quick sanity check and let me know whether to = publish. I also updated your bio: if you want extra mods, let me = know
Your account is linked to the above email = address: you may want to reset the password

Lars

On = 13 Apr 2016, at 16:24, Lars Kurth <lars.kurth.xen@gmail.com> wrote:

Tamas,

apologies. I missed this = in my inbox ...

I made a few minor suggestions: mainly shortening some = sentences. 
There are also a couple of = questions

Do = you want me to upload this to the blog (under your username)? Where do = you want to insert the png's?

On 25 = Jan 2016, at 20:51, Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi all,
here is an updated version. Also, a couple pictures that = could be used as illustrations. Feel free to punch it up as needed ;)

Tamas


Stealthy monitoring with Xen altp2m

One of the core features that differentiates Xen from other = open-source hypervisors is its native support for stealthy and secure = monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer =

"In = Xen 4.6 which was was released last autumn"

several new features have been = introduced that make this subsystem better; a cleaned-up, optimized API = and ARM support being just some of the biggest items on this list. As = part of this release of Xen, a new and unique feature was also = successfully added by a team from Intel that make stealthy monitoring = even better on Xen: altp2m. In this blog entry we will take a look at = what it's all about.

In Xen's terminology, = p2m stands for the memory management layer that handles the translation = from guest [p]hysical memory to [m]achine physical. This translation is = critical for safely partitioning the real memory of machine between Xen = and the various VMs running as to ensure a VM can't simply access the = memory of another. There are several implementations of = this

There are several implementations of this mechanism,

including one = with hardware support via Intel Extended Page Tables (EPT) available to = HVM (and PVH) guests

and PVH <guests>.

, called Hardware = Assisted Paging (hap) in Xen's terminology. =

In Xen's terminology, this is called Hardware Assisted Paging = (hap).

In this = implementation the hypervisor maintains a second pagetable, similar to = the one in 64-bit operating systems use, dedicated to running the p2m = translation. All (open-source) hypervisors that use this hardware = assisted paging method use a single EPT per virtual machine to handle = this translation, as most of the time the memory of the guest is = assigned at VM creation an doesn't change much afterwards.

Xen altp2m is the first implementation which = changes this setup by allowing Xen to create more then one EPT for each = guest. Interestingly, the Intel hardware has been capable of maintaining = up to 512 EPT pointers in the VMCS since the first introduction of EPT; = however, noone made use of this capability until now. This changed in = Xen 4.6, where we can now create of up to 10 EPTs per guest. The primary = reason for this extension is of course the new #VE and VMFUNC extensions = that were released in the Skylake generation of CPUs (which is worth a = whole blog-entry on its own), but it can also be used by external = monitoring applications via the Xen vm_event system.

It can also be used by external monitoring applications = via the Xen vm_event system.

Add a sub-headline: Why alt2pm is a = game-changer


Why this feature is a game-changer for = applications performing purely external monitoring is because it = simplifies the monitoring process of multi-vCPU guests. =

Alt2pm= is a game-changer for applications performing purely external = monitoring is because it simplifies the monitoring process of multi-vCPU = guests.

The= EPT layer has been successfully used in stealthy monitoring = applications to track the memory accesses made by the VM from a safe = vantage point by restricting the type of access the VM may perform on = various memory pages. Since EPT permission violations trap into the = hypervisor, the VM would receive no indication that anything out of the = ordinary has happened. While the method allowed for stealthy tracing of = R/W/X memory accesses of the guest, the memory permission needs to be = relaxed in order to allow the guest to continue execution. When a single = EPT is shared across multiple running vCPUs, relaxing the permissions to = allow one vCPU to continue may inadvertantly allow another one to = perform the memory access we would otherwise want to track. While under = normal circumstances such race-condition may rarely occur, malicious = code could easily use this to hide some of its actions from a monitoring = application.

Solutions to this problem = exist already. For example we can pause all vCPUs while the one = violating the access is singlestepped. This approach however introduces = heavy overhead just to avoid a race-condition that may rarely occur in = practice. Alternatively, one could emulate the instruction that was = violating the EPT permission without relaxing the EPT access = permissions, as Xen's built-in emulator doesn't use EPT to access the = guest memory. This solution, while supported in Xen, is not particularly = ideal either as Xen's emulator is incomplete and is known to have issues = that can lead to guest instability [2]. Furthermore, over the years = emulation has been a hotbed of various security issues in many = hypervisors (including Xen [3]), thus building security tools based on = emulation is simply asking for trouble. It can be handy but should be = used only when no other option is available.

Xen's altp2m system changes this problem quite significantly. = By having multiple EPTs we can have differing access permissions defined = in each table, which can be easily swapped around by changing the active = EPT index in the VMCS. When the guest makes a memory access that is = monitored, instead of having to relax the access permission, Xen can = simply switch to an EPT (called a view) that allows the operation to = continue. Afterwards the permissive view can be switched back to the = restriced view to continue monitoring. Since each vCPU has its own VMCS = where this switching is performed, this monitoring can be performed = specific to each vCPU, without having to pause any of the other ones, or = having to emulate the access. All without the guest noticing any of this = switching at all. A truly simple and elegant solution.


Add a sub-headline: Other introspection methods for = stealthy monitoring

Of course, EPT based monitoring is not the only introspecting = technique used for stealthy monitoring. For example, the Xen based = DRAKVUF Dynamic Malware Analysis [4] uses it in combination with an = additional technique to maximum effect. =

The= main motivation for that is because EPT based monitoring is known to = introduce significant overhead, even with altp2m: the granularity of the = monitoring is that of a memory page = (4KB).

This sentence is a bit convoluted and I = lost you here. Not quite sure what you are trying to say

If the monitoring application is = really just interested, for example, when a function-entry point is = called, EPT based monitoring creates a lot of "false" events when that = page is accessed for the rest of the function's code. =

Again,= something seems to be missing here and I am struggling to understand =  what you are trying to say

Fortunately, this can be avoided = by enabling the trapping of debug instructions into the hypervisor, a = built-in feature of Intel CPUs that Xen exposes to third-party = applications. This method is used in DRAKVUF, which writes breakpoint = instructions into the guests' memory at code-locations of interest. = Since we will only get an event for precisely the code-location we are = interested in this method effectively reduces the overhead. However, the = trade-off is that unlike EPT permissions the breakpoints are now visible = to the guest. Thus, to hide the presence of the breakpoints from the = guest, these pages need to get further protected by restricting the = pages to be execute-only in the EPT. This allows DRAKVUF to remove the = breakpoints before in-guest code-integrity checking mechanisms (like = Windows Patchguard) can access the page. While with altp2m the EPT = permissions can be safely used with multi-vCPU systems, using = breakpoints similarly presents a race-condition: the breakpoint hit by = one vCPU has to be removed to allow the guest to execute the instruction = that was originally overwritten, potentially allowing another vCPU to do = so as well without notice.

Fortunately, = altp2m has another neat feature that can be used to solve this problem. = Beside allowing for changing the memory permissions in the different = altp2m views, it also allows to change the mapping itself! The same = guest physical memory can be setup to be backed by different pages in = the different views. With this feature we can really thing of guest = physical

assuming: thing=3Dthink

memory as  "virtual": where = it is mapped really depends on which view the vCPU is running on. Using = this feature allows us to hide the presence of the breakpoints in a = brand new way. To do this, first  we create a complete shadow copy = of the memory page where a breakpoint is going to be written and only = write the breakpoint into this shadow copy. Now, using altp2m, we setup = a view where the guest physical memory of the page gets mapped to our = shadow copy. The guest continues to access its physical memory as = before, but underneath it is now using the trapped shadow copy. When the = breakpoint is hit, or if something is trying to scan the code, we simply = switch the view to the un-altered view for the duration of a singlestep, = then switch back to the trapped view. This allows us to hide the = presence of the breakpoints specific to each vCPU! All without having = pause any of the other vCPUs or having to emulate. The first open-source = implementation of this tracing has been already merged into the DRAKVUF = Malware Analysis System and is available as a reference implementation = for those interested in more details.

As we = can see, Xen continues to be on the forefront of advancing the = development of virtualization based security application and allowing = third-party tools to create some very exotic setups. This flexibility is = what's so great about Xen and why it will continue to be a trend-setter = for the foreseeable future.


Add a sub-headline: References

[1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection
[2] http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.h= tml
[3] https://blog.xenproject.org/2015/05/14/hardening-hypervisors-ag= ainst-venom-style-attacks/
[4] http://drakvuf.com
<altp2m.png><altp2m-shadow.png><p2m.png>


= --Apple-Mail=_50884264-0431-45DD-BFE5-121396905568-- --===============8126900994177111711== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============8126900994177111711==-- From publicity-bounces@lists.xenproject.org Wed Apr 13 16:31:10 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 16:31:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNh7-0005Vl-Te; Wed, 13 Apr 2016 16:31:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNOo-0004Bh-Ua for publicity@lists.xenproject.org; Wed, 13 Apr 2016 16:12:15 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 45/23-16306-EDF6E075; Wed, 13 Apr 2016 16:12:14 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRWlGSWpSXmKPExsXiVRuko3snny/ cYEeHqcXvvrWMDowehz9cYQlgjGLNzEvKr0hgzTh4ZitTQdspxooXvZfYGxg3r2bsYuTiEBKY ySjx981fdhCHRaCBVeJl2xMmEEdCYA6rxMl/01m7GDmBnByJYz8vgNm8AoISJ2c+YYGIl0js2 /kWLC4k4CVxYP5VdhCbU8BW4uvdUywQ8R8sEvvXM4LYLAKqEks23mSHmBMgseN8ExuILSxgI3 Hs5D2wOWwChhKP9nxlBrFFBDQlJl7bDxZnBtrV0zCTEcL2kvi2Zy/bBEaBWUhOmoUkNYuRA8h Wl1g/TwgirCZxe9tVdghbW2LZwtfMCxhZVzGqF6cWlaUW6ZrpJRVlpmeU5CZm5ugaGpjq5aYW Fyemp+YkJhXrJefnbmIEhjQDEOxgnNrgfIhRkoNJSZRXLJcvXIgvKT+lMiOxOCO+qDQntfgQo wwHh5IErwgwRoQEi1LTUyvSMnOA0QWTluDgURLhfZIHlOYtLkjMLc5Mh0idYtTl2DL13lomIZ a8/LxUKXFeAZAZAiBFGaV5cCNgkX6JUVZKmJcR6CghnoLUotzMElT5V4ziHIxKwryvQFbxZOa VwG16BXQEE9ARZe94QY4oSURISTUwLj1crf5a7Hz+3gVx8+zqRbo01ri8jFAoL1/IfWT38+K8 onZzH9+lJ3Ws5ufemRumozkxfzrj/FsacXqOB1LCTOatvJfccTfx460S/vDTDU4L3hnlV84LK 9D0WKmpnrhsS+qP2RkCYTOZl/j8/3D57RZe/0Vsqbb12yon3Dmww6tl8ZqFafJrlFiKMxINtZ iLihMBFS44LO8CAAA= X-Env-Sender: tamas.k.lengyel@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1460563932!34283606!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 65434 invoked from network); 13 Apr 2016 16:12:12 -0000 Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by server-6.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 16:12:12 -0000 Received: by mail-wm0-f44.google.com with SMTP id u206so87123124wme.1 for ; Wed, 13 Apr 2016 09:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=88pOL8wpPDaL8OUrcvMKM/uiYrjdexbX+NDsUISSN4M=; b=rKyqAHhoySurnGzCw7ND7kkzfCWebRN+ABVobTOc1UB/ipu3iJXIKKa6qbUUbSf4yo htll6Aitagiw65x61oIIsH4V5r9bKyIm0WUUFO8IzbNugQbiOYwGZhnA3P9rEPK8EzcS YEPgraB1/+TmLqAX9mZNYp3UoX9KOcv4vHTOf/ped1iqil9qTPmM6oboYJZzMNgHJ1Kp GdyeJovYjMdKAAYoj+ZgblhOXaLN4Sx/34yuHLrCVeCB/lTOACHtgKoJzqaDwVyfjzD/ NjKFbUUCZk1EOrfknSa1aD6zgrtoVVjzcyuGgZorY4Y5sqwIesQm2WH4bKdy3wz7HUWz goYA== 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; bh=88pOL8wpPDaL8OUrcvMKM/uiYrjdexbX+NDsUISSN4M=; b=cxWty97Wk+4cuJ66hBFWAc/M1ZJtVd+qOXe3ubHHxdUvv+FP9oEKU3hY0Iysnsnrod j69lzQ+4G7EBBfPyeQbLOiHftdSr8ufdoTvHLMXIRoCA77oXzgb5TEMKB4l1ftGu+VAT AgG8LDODmhuOR/qPoc02+OuS4H/xUvB+LQxWNPFBJeySD95X9PbIwuMmA7gmChbwzrg0 nljY+4XXaOIOSmk2IKU6xaVd9dM07wr9dMaUB5x9FozSrqWiQaM6mdm77hXBKXj8lOqP iLDQH7wrHGWmz501p0AoFTklN29B/ohAO3UU7Ze+s+sCzDLkhiKZwYtXeHhrNHlYHP4i KYEA== X-Gm-Message-State: AOPr4FUNgN9gkjligy4EOgvQirAqtNc+lE11dUkPVw5SG/499GC2TJ4Ae8v9PTu1pld0NMxeddFD+w8FnP6Hww== MIME-Version: 1.0 X-Received: by 10.194.92.107 with SMTP id cl11mr11771747wjb.21.1460563932360; Wed, 13 Apr 2016 09:12:12 -0700 (PDT) Received: by 10.28.41.194 with HTTP; Wed, 13 Apr 2016 09:12:12 -0700 (PDT) In-Reply-To: <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> Date: Wed, 13 Apr 2016 10:12:12 -0600 Message-ID: From: Tamas K Lengyel To: Lars Kurth X-Mailman-Approved-At: Wed, 13 Apr 2016 16:31:09 +0000 Cc: "publicity@lists.xenproject.org" Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============1939690588781400077==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============1939690588781400077== Content-Type: multipart/alternative; boundary=047d7bf0d2d45c35240530600aa3 --047d7bf0d2d45c35240530600aa3 Content-Type: text/plain; charset=UTF-8 Hey Lars, I've fixed some minor things and it looks good now! Thanks, Tamas On Wed, Apr 13, 2016 at 9:59 AM, Lars Kurth wrote: > Draft blog at https://blog.xenproject.org/?p=11282&preview=true > > @Tamas > Please do a quick sanity check and let me know whether to publish. I also > updated your bio: if you want extra mods, let me know > Your account is linked to the above email address: you may want to reset > the password > > Lars > > On 13 Apr 2016, at 16:24, Lars Kurth wrote: > > Tamas, > > apologies. I missed this in my inbox ... > > I made a few minor suggestions: mainly shortening some sentences. > There are also a couple of questions > > Do you want me to upload this to the blog (under your username)? Where do > you want to insert the png's? > > On 25 Jan 2016, at 20:51, Lengyel, Tamas wrote: > > Hi all, > here is an updated version. Also, a couple pictures that could be used as > illustrations. Feel free to punch it up as needed ;) > > Tamas > > > Stealthy monitoring with Xen altp2m > > One of the core features that differentiates Xen from other open-source > hypervisors is its native support for stealthy and secure monitoring of > guest internals (aka. virtual machine introspection [1]). In the latest > release of Xen last summer > > > "In Xen 4.6 which was was released last autumn" > > several new features have been introduced that make this subsystem better; > a cleaned-up, optimized API and ARM support being just some of the biggest > items on this list. As part of this release of Xen, a new and unique > feature was also successfully added by a team from Intel that make stealthy > monitoring even better on Xen: altp2m. In this blog entry we will take a > look at what it's all about. > > In Xen's terminology, p2m stands for the memory management layer that > handles the translation from guest [p]hysical memory to [m]achine physical. > This translation is critical for safely partitioning the real memory of > machine between Xen and the various VMs running as to ensure a VM can't > simply access the memory of another. There are several implementations of > this > > > There are several implementations of this mechanism, > > including one with hardware support via Intel Extended Page Tables (EPT) > available to HVM (and PVH) guests > > > and PVH . > > , called Hardware Assisted Paging (hap) in Xen's terminology. > > > In Xen's terminology, this is called Hardware Assisted Paging (hap). > > In this implementation the hypervisor maintains a second pagetable, > similar to the one in 64-bit operating systems use, dedicated to running > the p2m translation. All (open-source) hypervisors that use this hardware > assisted paging method use a single EPT per virtual machine to handle this > translation, as most of the time the memory of the guest is assigned at VM > creation an doesn't change much afterwards. > > Xen altp2m is the first implementation which changes this setup by > allowing Xen to create more then one EPT for each guest. Interestingly, the > Intel hardware has been capable of maintaining up to 512 EPT pointers in > the VMCS since the first introduction of EPT; however, noone made use of > this capability until now. This changed in Xen 4.6, where we can now create > of up to 10 EPTs per guest. The primary reason for this extension is of > course the new #VE and VMFUNC extensions that were released in the Skylake > generation of CPUs (which is worth a whole blog-entry on its own), but it > can also be used by external monitoring applications via the Xen vm_event > system. > > > It can also be used by external monitoring applications via the Xen > vm_event system. > > Add a sub-headline: Why alt2pm is a game-changer > > > Why this feature is a game-changer for applications performing purely > external monitoring is because it simplifies the monitoring process of > multi-vCPU guests. > > > Alt2pm is a game-changer for applications performing purely external > monitoring is because it simplifies the monitoring process of multi-vCPU > guests. > > The EPT layer has been successfully used in stealthy monitoring > applications to track the memory accesses made by the VM from a safe > vantage point by restricting the type of access the VM may perform on > various memory pages. Since EPT permission violations trap into the > hypervisor, the VM would receive no indication that anything out of the > ordinary has happened. While the method allowed for stealthy tracing of > R/W/X memory accesses of the guest, the memory permission needs to be > relaxed in order to allow the guest to continue execution. When a single > EPT is shared across multiple running vCPUs, relaxing the permissions to > allow one vCPU to continue may inadvertantly allow another one to perform > the memory access we would otherwise want to track. While under normal > circumstances such race-condition may rarely occur, malicious code could > easily use this to hide some of its actions from a monitoring application. > > Solutions to this problem exist already. For example we can pause all > vCPUs while the one violating the access is singlestepped. This approach > however introduces heavy overhead just to avoid a race-condition that may > rarely occur in practice. Alternatively, one could emulate the instruction > that was violating the EPT permission without relaxing the EPT access > permissions, as Xen's built-in emulator doesn't use EPT to access the guest > memory. This solution, while supported in Xen, is not particularly ideal > either as Xen's emulator is incomplete and is known to have issues that can > lead to guest instability [2]. Furthermore, over the years emulation has > been a hotbed of various security issues in many hypervisors (including Xen > [3]), thus building security tools based on emulation is simply asking for > trouble. It can be handy but should be used only when no other option is > available. > > Xen's altp2m system changes this problem quite significantly. By having > multiple EPTs we can have differing access permissions defined in each > table, which can be easily swapped around by changing the active EPT index > in the VMCS. When the guest makes a memory access that is monitored, > instead of having to relax the access permission, Xen can simply switch to > an EPT (called a view) that allows the operation to continue. Afterwards > the permissive view can be switched back to the restriced view to continue > monitoring. Since each vCPU has its own VMCS where this switching is > performed, this monitoring can be performed specific to each vCPU, without > having to pause any of the other ones, or having to emulate the access. All > without the guest noticing any of this switching at all. A truly simple and > elegant solution. > > > Add a sub-headline: Other introspection methods for stealthy monitoring > > Of course, EPT based monitoring is not the only introspecting technique > used for stealthy monitoring. For example, the Xen based DRAKVUF Dynamic > Malware Analysis [4] uses it in combination with an additional technique to > maximum effect. > > > The main motivation for that is because EPT based monitoring is known to > introduce significant overhead, even with altp2m: the granularity of the > monitoring is that of a memory page (4KB). > > > This sentence is a bit convoluted and I lost you here. Not quite sure what > you are trying to say > > If the monitoring application is really just interested, for example, when > a function-entry point is called, EPT based monitoring creates a lot of > "false" events when that page is accessed for the rest of the function's > code. > > > Again, something seems to be missing here and I am struggling to > understand what you are trying to say > > Fortunately, this can be avoided by enabling the trapping of debug > instructions into the hypervisor, a built-in feature of Intel CPUs that Xen > exposes to third-party applications. This method is used in DRAKVUF, which > writes breakpoint instructions into the guests' memory at code-locations of > interest. Since we will only get an event for precisely the code-location > we are interested in this method effectively reduces the overhead. However, > the trade-off is that unlike EPT permissions the breakpoints are now > visible to the guest. Thus, to hide the presence of the breakpoints from > the guest, these pages need to get further protected by restricting the > pages to be execute-only in the EPT. This allows DRAKVUF to remove the > breakpoints before in-guest code-integrity checking mechanisms (like > Windows Patchguard) can access the page. While with altp2m the EPT > permissions can be safely used with multi-vCPU systems, using breakpoints > similarly presents a race-condition: the breakpoint hit by one vCPU has to > be removed to allow the guest to execute the instruction that was > originally overwritten, potentially allowing another vCPU to do so as well > without notice. > > Fortunately, altp2m has another neat feature that can be used to solve > this problem. Beside allowing for changing the memory permissions in the > different altp2m views, it also allows to change the mapping itself! The > same guest physical memory can be setup to be backed by different pages in > the different views. With this feature we can really thing of guest > physical > > > assuming: thing=think > > memory as "virtual": where it is mapped really depends on which view the > vCPU is running on. Using this feature allows us to hide the presence of > the breakpoints in a brand new way. To do this, first we create a complete > shadow copy of the memory page where a breakpoint is going to be written > and only write the breakpoint into this shadow copy. Now, using altp2m, we > setup a view where the guest physical memory of the page gets mapped to our > shadow copy. The guest continues to access its physical memory as before, > but underneath it is now using the trapped shadow copy. When the breakpoint > is hit, or if something is trying to scan the code, we simply switch the > view to the un-altered view for the duration of a singlestep, then switch > back to the trapped view. This allows us to hide the presence of the > breakpoints specific to each vCPU! All without having pause any of the > other vCPUs or having to emulate. The first open-source implementation of > this tracing has been already merged into the DRAKVUF Malware Analysis > System and is available as a reference implementation for those interested > in more details. > > As we can see, Xen continues to be on the forefront of advancing the > development of virtualization based security application and allowing > third-party tools to create some very exotic setups. This flexibility is > what's so great about Xen and why it will continue to be a trend-setter for > the foreseeable future. > > > Add a sub-headline: References > > [1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection > [2] http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.html > [3] > https://blog.xenproject.org/2015/05/14/hardening-hypervisors-against-venom-style-attacks/ > [4] http://drakvuf.com > > > > > --047d7bf0d2d45c35240530600aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Lars,
I've fixed some mino= r things and it looks good now!

Thanks,
Tamas

On Wed, Apr 13,= 2016 at 9:59 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Draft blog at=C2=A0https://blog.xenproject.org/?p=3D11282= &preview=3Dtrue

@Tamas
Please do a qui= ck sanity check and let me know whether to publish. I also updated your bio= : if you want extra mods, let me know
Your account is linked to t= he above email address: you may want to reset the password

Lars

On 13 Apr 2= 016, at 16:24, Lars Kurth <lars.kurth.xen@gmail.com> wrote:

Tamas,

apologies. I miss= ed this in my inbox ...

I made a few minor suggest= ions: mainly shortening some sentences.=C2=A0
There are also a co= uple of questions

Do you want me to upload this to= the blog (under your username)? Where do you want to insert the png's?=

On 25 Jan 2016, at 20:51= , Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi all,
here is an updated version. Also, a couple pictures = that could be used as illustrations. Feel free to punch it up as needed ;)<= br>
Tamas

Stealthy monitoring = with Xen altp2m

One of the core features that differentiates Xen fro= m other open-source hypervisors is its native support for stealthy and secu= re monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer

"In Xen 4.6 which was was released last autumn"
=

several new f= eatures have been introduced that make this subsystem better; a cleaned-up,= optimized API and ARM support being just some of the biggest items on this= list. As part of this release of Xen, a new and unique feature was also su= ccessfully added by a team from Intel that make stealthy monitoring even be= tter on Xen: altp2m. In this blog entry we will take a look at what it'= s all about.

In Xen's terminology, p2m stands for the memory man= agement layer that handles the translation from guest [p]hysical memory to = [m]achine physical. This translation is critical for safely partitioning th= e real memory of machine between Xen and the various VMs running as to ensu= re a VM can't simply access the memory of another. There are several im= plementations of this

There ar= e several implementations of this mechanism,

including one with hardware support via Inte= l Extended Page Tables (EPT) available to HVM (and PVH) guests
<= /div>

and PVH <guests>.

, called Hardwa= re Assisted Paging (hap) in Xen's terminology.

In Xen's terminology, this is called Hardwar= e Assisted Paging (hap).

In this implementation the hypervisor maintains a second page= table, similar to the one in 64-bit operating systems use, dedicated to run= ning the p2m translation. All (open-source) hypervisors that use this hardw= are assisted paging method use a single EPT per virtual machine to handle t= his translation, as most of the time the memory of the guest is assigned at= VM creation an doesn't change much afterwards.

Xen altp2m is th= e first implementation which changes this setup by allowing Xen to create m= ore then one EPT for each guest. Interestingly, the Intel hardware has been= capable of maintaining up to 512 EPT pointers in the VMCS since the first = introduction of EPT; however, noone made use of this capability until now. = This changed in Xen 4.6, where we can now create of up to 10 EPTs per guest= . The primary reason for this extension is of course the new #VE and VMFUNC= extensions that were released in the Skylake generation of CPUs (which is = worth a whole blog-entry on its own), but it can also be used by external m= onitoring applications via the Xen vm_event system.

It can also be used by external monitoring applic= ations via the Xen vm_event system.

Add a sub-head= line: Why alt2pm is a game-changer

=

Why this feature is a game-changer for appli= cations performing purely external monitoring is because it simplifies the = monitoring process of multi-vCPU guests.

Alt2pm is a game-changer for applications performing purely ext= ernal monitoring is because it simplifies the monitoring process of multi-v= CPU guests.

<= div>The EPT layer has been successfully used in stealthy monitoring applica= tions to track the memory accesses made by the VM from a safe vantage point= by restricting the type of access the VM may perform on various memory pag= es. Since EPT permission violations trap into the hypervisor, the VM would = receive no indication that anything out of the ordinary has happened. While= the method allowed for stealthy tracing of R/W/X memory accesses of the gu= est, the memory permission needs to be relaxed in order to allow the guest = to continue execution. When a single EPT is shared across multiple running = vCPUs, relaxing the permissions to allow one vCPU to continue may inadverta= ntly allow another one to perform the memory access we would otherwise want= to track. While under normal circumstances such race-condition may rarely = occur, malicious code could easily use this to hide some of its actions fro= m a monitoring application.

Solutions to this problem exist already.= For example we can pause all vCPUs while the one violating the access is s= inglestepped. This approach however introduces heavy overhead just to avoid= a race-condition that may rarely occur in practice. Alternatively, one cou= ld emulate the instruction that was violating the EPT permission without re= laxing the EPT access permissions, as Xen's built-in emulator doesn'= ;t use EPT to access the guest memory. This solution, while supported in Xe= n, is not particularly ideal either as Xen's emulator is incomplete and= is known to have issues that can lead to guest instability [2]. Furthermor= e, over the years emulation has been a hotbed of various security issues in= many hypervisors (including Xen [3]), thus building security tools based o= n emulation is simply asking for trouble. It can be handy but should be use= d only when no other option is available.

Xen's altp2m system ch= anges this problem quite significantly. By having multiple EPTs we can have= differing access permissions defined in each table, which can be easily sw= apped around by changing the active EPT index in the VMCS. When the guest m= akes a memory access that is monitored, instead of having to relax the acce= ss permission, Xen can simply switch to an EPT (called a view) that allows = the operation to continue. Afterwards the permissive view can be switched b= ack to the restriced view to continue monitoring. Since each vCPU has its o= wn VMCS where this switching is performed, this monitoring can be performed= specific to each vCPU, without having to pause any of the other ones, or h= aving to emulate the access. All without the guest noticing any of this swi= tching at all. A truly simple and elegant solution.


Add a sub-headline: Other introspection metho= ds for stealthy monitoring

Of course, EPT based monitoring is not the only introspe= cting technique used for stealthy monitoring. For example, the Xen based DR= AKVUF Dynamic Malware Analysis [4] uses it in combination with an additiona= l technique to maximum effect.

The main motivation for that is= because EPT based monitoring is known to introduce significant overhead, e= ven with altp2m: the granularity of the monitoring is that of a memory page= (4KB).

This sentence is = a bit convoluted and I lost you here. Not quite sure what you are trying to= say

If the = monitoring application is really just interested, for example, when a funct= ion-entry point is called, EPT based monitoring creates a lot of "fals= e" events when that page is accessed for the rest of the function'= s code.

Again, something seem= s to be missing here and I am struggling to understand =C2=A0what you are t= rying to say

=
Fortunately, this can be avoided by enabling the trapping of debug ins= tructions into the hypervisor, a built-in feature of Intel CPUs that Xen ex= poses to third-party applications. This method is used in DRAKVUF, which wr= ites breakpoint instructions into the guests' memory at code-locations = of interest. Since we will only get an event for precisely the code-locatio= n we are interested in this method effectively reduces the overhead. Howeve= r, the trade-off is that unlike EPT permissions the breakpoints are now vis= ible to the guest. Thus, to hide the presence of the breakpoints from the g= uest, these pages need to get further protected by restricting the pages to= be execute-only in the EPT. This allows DRAKVUF to remove the breakpoints = before in-guest code-integrity checking mechanisms (like Windows Patchguard= ) can access the page. While with altp2m the EPT permissions can be safely = used with multi-vCPU systems, using breakpoints similarly presents a race-c= ondition: the breakpoint hit by one vCPU has to be removed to allow the gue= st to execute the instruction that was originally overwritten, potentially = allowing another vCPU to do so as well without notice.

Fortunately, = altp2m has another neat feature that can be used to solve this problem. Bes= ide allowing for changing the memory permissions in the different altp2m vi= ews, it also allows to change the mapping itself! The same guest physical m= emory can be setup to be backed by different pages in the different views. = With this feature we can really thing of guest physical
<= /blockquote>

assuming: thing=3Dthink

memory as=C2=A0 "virtual&qu= ot;: where it is mapped really depends on which view the vCPU is running on= . Using this feature allows us to hide the presence of the breakpoints in a= brand new way. To do this, first=C2=A0 we create a complete shadow copy of= the memory page where a breakpoint is going to be written and only write t= he breakpoint into this shadow copy. Now, using altp2m, we setup a view whe= re the guest physical memory of the page gets mapped to our shadow copy. Th= e guest continues to access its physical memory as before, but underneath i= t is now using the trapped shadow copy. When the breakpoint is hit, or if s= omething is trying to scan the code, we simply switch the view to the un-al= tered view for the duration of a singlestep, then switch back to the trappe= d view. This allows us to hide the presence of the breakpoints specific to = each vCPU! All without having pause any of the other vCPUs or having to emu= late. The first open-source implementation of this tracing has been already= merged into the DRAKVUF Malware Analysis System and is available as a refe= rence implementation for those interested in more details.

As we can= see, Xen continues to be on the forefront of advancing the development of = virtualization based security application and allowing third-party tools to= create some very exotic setups. This flexibility is what's so great ab= out Xen and why it will continue to be a trend-setter for the foreseeable f= uture.


Add a sub-headl= ine: References




--047d7bf0d2d45c35240530600aa3-- --===============1939690588781400077== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============1939690588781400077==-- From publicity-bounces@lists.xenproject.org Wed Apr 13 16:31:10 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 16:31:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNh7-0005Vl-Te; Wed, 13 Apr 2016 16:31:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNOo-0004Bh-Ua for publicity@lists.xenproject.org; Wed, 13 Apr 2016 16:12:15 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 45/23-16306-EDF6E075; Wed, 13 Apr 2016 16:12:14 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRWlGSWpSXmKPExsXiVRuko3snny/ cYEeHqcXvvrWMDowehz9cYQlgjGLNzEvKr0hgzTh4ZitTQdspxooXvZfYGxg3r2bsYuTiEBKY ySjx981fdhCHRaCBVeJl2xMmEEdCYA6rxMl/01m7GDmBnByJYz8vgNm8AoISJ2c+YYGIl0js2 /kWLC4k4CVxYP5VdhCbU8BW4uvdUywQ8R8sEvvXM4LYLAKqEks23mSHmBMgseN8ExuILSxgI3 Hs5D2wOWwChhKP9nxlBrFFBDQlJl7bDxZnBtrV0zCTEcL2kvi2Zy/bBEaBWUhOmoUkNYuRA8h Wl1g/TwgirCZxe9tVdghbW2LZwtfMCxhZVzGqF6cWlaUW6ZrpJRVlpmeU5CZm5ugaGpjq5aYW Fyemp+YkJhXrJefnbmIEhjQDEOxgnNrgfIhRkoNJSZRXLJcvXIgvKT+lMiOxOCO+qDQntfgQo wwHh5IErwgwRoQEi1LTUyvSMnOA0QWTluDgURLhfZIHlOYtLkjMLc5Mh0idYtTl2DL13lomIZ a8/LxUKXFeAZAZAiBFGaV5cCNgkX6JUVZKmJcR6CghnoLUotzMElT5V4ziHIxKwryvQFbxZOa VwG16BXQEE9ARZe94QY4oSURISTUwLj1crf5a7Hz+3gVx8+zqRbo01ri8jFAoL1/IfWT38+K8 onZzH9+lJ3Ws5ufemRumozkxfzrj/FsacXqOB1LCTOatvJfccTfx460S/vDTDU4L3hnlV84LK 9D0WKmpnrhsS+qP2RkCYTOZl/j8/3D57RZe/0Vsqbb12yon3Dmww6tl8ZqFafJrlFiKMxINtZ iLihMBFS44LO8CAAA= X-Env-Sender: tamas.k.lengyel@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1460563932!34283606!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 65434 invoked from network); 13 Apr 2016 16:12:12 -0000 Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by server-6.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 16:12:12 -0000 Received: by mail-wm0-f44.google.com with SMTP id u206so87123124wme.1 for ; Wed, 13 Apr 2016 09:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=88pOL8wpPDaL8OUrcvMKM/uiYrjdexbX+NDsUISSN4M=; b=rKyqAHhoySurnGzCw7ND7kkzfCWebRN+ABVobTOc1UB/ipu3iJXIKKa6qbUUbSf4yo htll6Aitagiw65x61oIIsH4V5r9bKyIm0WUUFO8IzbNugQbiOYwGZhnA3P9rEPK8EzcS YEPgraB1/+TmLqAX9mZNYp3UoX9KOcv4vHTOf/ped1iqil9qTPmM6oboYJZzMNgHJ1Kp GdyeJovYjMdKAAYoj+ZgblhOXaLN4Sx/34yuHLrCVeCB/lTOACHtgKoJzqaDwVyfjzD/ NjKFbUUCZk1EOrfknSa1aD6zgrtoVVjzcyuGgZorY4Y5sqwIesQm2WH4bKdy3wz7HUWz goYA== 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; bh=88pOL8wpPDaL8OUrcvMKM/uiYrjdexbX+NDsUISSN4M=; b=cxWty97Wk+4cuJ66hBFWAc/M1ZJtVd+qOXe3ubHHxdUvv+FP9oEKU3hY0Iysnsnrod j69lzQ+4G7EBBfPyeQbLOiHftdSr8ufdoTvHLMXIRoCA77oXzgb5TEMKB4l1ftGu+VAT AgG8LDODmhuOR/qPoc02+OuS4H/xUvB+LQxWNPFBJeySD95X9PbIwuMmA7gmChbwzrg0 nljY+4XXaOIOSmk2IKU6xaVd9dM07wr9dMaUB5x9FozSrqWiQaM6mdm77hXBKXj8lOqP iLDQH7wrHGWmz501p0AoFTklN29B/ohAO3UU7Ze+s+sCzDLkhiKZwYtXeHhrNHlYHP4i KYEA== X-Gm-Message-State: AOPr4FUNgN9gkjligy4EOgvQirAqtNc+lE11dUkPVw5SG/499GC2TJ4Ae8v9PTu1pld0NMxeddFD+w8FnP6Hww== MIME-Version: 1.0 X-Received: by 10.194.92.107 with SMTP id cl11mr11771747wjb.21.1460563932360; Wed, 13 Apr 2016 09:12:12 -0700 (PDT) Received: by 10.28.41.194 with HTTP; Wed, 13 Apr 2016 09:12:12 -0700 (PDT) In-Reply-To: <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> Date: Wed, 13 Apr 2016 10:12:12 -0600 Message-ID: From: Tamas K Lengyel To: Lars Kurth X-Mailman-Approved-At: Wed, 13 Apr 2016 16:31:09 +0000 Cc: "publicity@lists.xenproject.org" Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============1939690588781400077==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============1939690588781400077== Content-Type: multipart/alternative; boundary=047d7bf0d2d45c35240530600aa3 --047d7bf0d2d45c35240530600aa3 Content-Type: text/plain; charset=UTF-8 Hey Lars, I've fixed some minor things and it looks good now! Thanks, Tamas On Wed, Apr 13, 2016 at 9:59 AM, Lars Kurth wrote: > Draft blog at https://blog.xenproject.org/?p=11282&preview=true > > @Tamas > Please do a quick sanity check and let me know whether to publish. I also > updated your bio: if you want extra mods, let me know > Your account is linked to the above email address: you may want to reset > the password > > Lars > > On 13 Apr 2016, at 16:24, Lars Kurth wrote: > > Tamas, > > apologies. I missed this in my inbox ... > > I made a few minor suggestions: mainly shortening some sentences. > There are also a couple of questions > > Do you want me to upload this to the blog (under your username)? Where do > you want to insert the png's? > > On 25 Jan 2016, at 20:51, Lengyel, Tamas wrote: > > Hi all, > here is an updated version. Also, a couple pictures that could be used as > illustrations. Feel free to punch it up as needed ;) > > Tamas > > > Stealthy monitoring with Xen altp2m > > One of the core features that differentiates Xen from other open-source > hypervisors is its native support for stealthy and secure monitoring of > guest internals (aka. virtual machine introspection [1]). In the latest > release of Xen last summer > > > "In Xen 4.6 which was was released last autumn" > > several new features have been introduced that make this subsystem better; > a cleaned-up, optimized API and ARM support being just some of the biggest > items on this list. As part of this release of Xen, a new and unique > feature was also successfully added by a team from Intel that make stealthy > monitoring even better on Xen: altp2m. In this blog entry we will take a > look at what it's all about. > > In Xen's terminology, p2m stands for the memory management layer that > handles the translation from guest [p]hysical memory to [m]achine physical. > This translation is critical for safely partitioning the real memory of > machine between Xen and the various VMs running as to ensure a VM can't > simply access the memory of another. There are several implementations of > this > > > There are several implementations of this mechanism, > > including one with hardware support via Intel Extended Page Tables (EPT) > available to HVM (and PVH) guests > > > and PVH . > > , called Hardware Assisted Paging (hap) in Xen's terminology. > > > In Xen's terminology, this is called Hardware Assisted Paging (hap). > > In this implementation the hypervisor maintains a second pagetable, > similar to the one in 64-bit operating systems use, dedicated to running > the p2m translation. All (open-source) hypervisors that use this hardware > assisted paging method use a single EPT per virtual machine to handle this > translation, as most of the time the memory of the guest is assigned at VM > creation an doesn't change much afterwards. > > Xen altp2m is the first implementation which changes this setup by > allowing Xen to create more then one EPT for each guest. Interestingly, the > Intel hardware has been capable of maintaining up to 512 EPT pointers in > the VMCS since the first introduction of EPT; however, noone made use of > this capability until now. This changed in Xen 4.6, where we can now create > of up to 10 EPTs per guest. The primary reason for this extension is of > course the new #VE and VMFUNC extensions that were released in the Skylake > generation of CPUs (which is worth a whole blog-entry on its own), but it > can also be used by external monitoring applications via the Xen vm_event > system. > > > It can also be used by external monitoring applications via the Xen > vm_event system. > > Add a sub-headline: Why alt2pm is a game-changer > > > Why this feature is a game-changer for applications performing purely > external monitoring is because it simplifies the monitoring process of > multi-vCPU guests. > > > Alt2pm is a game-changer for applications performing purely external > monitoring is because it simplifies the monitoring process of multi-vCPU > guests. > > The EPT layer has been successfully used in stealthy monitoring > applications to track the memory accesses made by the VM from a safe > vantage point by restricting the type of access the VM may perform on > various memory pages. Since EPT permission violations trap into the > hypervisor, the VM would receive no indication that anything out of the > ordinary has happened. While the method allowed for stealthy tracing of > R/W/X memory accesses of the guest, the memory permission needs to be > relaxed in order to allow the guest to continue execution. When a single > EPT is shared across multiple running vCPUs, relaxing the permissions to > allow one vCPU to continue may inadvertantly allow another one to perform > the memory access we would otherwise want to track. While under normal > circumstances such race-condition may rarely occur, malicious code could > easily use this to hide some of its actions from a monitoring application. > > Solutions to this problem exist already. For example we can pause all > vCPUs while the one violating the access is singlestepped. This approach > however introduces heavy overhead just to avoid a race-condition that may > rarely occur in practice. Alternatively, one could emulate the instruction > that was violating the EPT permission without relaxing the EPT access > permissions, as Xen's built-in emulator doesn't use EPT to access the guest > memory. This solution, while supported in Xen, is not particularly ideal > either as Xen's emulator is incomplete and is known to have issues that can > lead to guest instability [2]. Furthermore, over the years emulation has > been a hotbed of various security issues in many hypervisors (including Xen > [3]), thus building security tools based on emulation is simply asking for > trouble. It can be handy but should be used only when no other option is > available. > > Xen's altp2m system changes this problem quite significantly. By having > multiple EPTs we can have differing access permissions defined in each > table, which can be easily swapped around by changing the active EPT index > in the VMCS. When the guest makes a memory access that is monitored, > instead of having to relax the access permission, Xen can simply switch to > an EPT (called a view) that allows the operation to continue. Afterwards > the permissive view can be switched back to the restriced view to continue > monitoring. Since each vCPU has its own VMCS where this switching is > performed, this monitoring can be performed specific to each vCPU, without > having to pause any of the other ones, or having to emulate the access. All > without the guest noticing any of this switching at all. A truly simple and > elegant solution. > > > Add a sub-headline: Other introspection methods for stealthy monitoring > > Of course, EPT based monitoring is not the only introspecting technique > used for stealthy monitoring. For example, the Xen based DRAKVUF Dynamic > Malware Analysis [4] uses it in combination with an additional technique to > maximum effect. > > > The main motivation for that is because EPT based monitoring is known to > introduce significant overhead, even with altp2m: the granularity of the > monitoring is that of a memory page (4KB). > > > This sentence is a bit convoluted and I lost you here. Not quite sure what > you are trying to say > > If the monitoring application is really just interested, for example, when > a function-entry point is called, EPT based monitoring creates a lot of > "false" events when that page is accessed for the rest of the function's > code. > > > Again, something seems to be missing here and I am struggling to > understand what you are trying to say > > Fortunately, this can be avoided by enabling the trapping of debug > instructions into the hypervisor, a built-in feature of Intel CPUs that Xen > exposes to third-party applications. This method is used in DRAKVUF, which > writes breakpoint instructions into the guests' memory at code-locations of > interest. Since we will only get an event for precisely the code-location > we are interested in this method effectively reduces the overhead. However, > the trade-off is that unlike EPT permissions the breakpoints are now > visible to the guest. Thus, to hide the presence of the breakpoints from > the guest, these pages need to get further protected by restricting the > pages to be execute-only in the EPT. This allows DRAKVUF to remove the > breakpoints before in-guest code-integrity checking mechanisms (like > Windows Patchguard) can access the page. While with altp2m the EPT > permissions can be safely used with multi-vCPU systems, using breakpoints > similarly presents a race-condition: the breakpoint hit by one vCPU has to > be removed to allow the guest to execute the instruction that was > originally overwritten, potentially allowing another vCPU to do so as well > without notice. > > Fortunately, altp2m has another neat feature that can be used to solve > this problem. Beside allowing for changing the memory permissions in the > different altp2m views, it also allows to change the mapping itself! The > same guest physical memory can be setup to be backed by different pages in > the different views. With this feature we can really thing of guest > physical > > > assuming: thing=think > > memory as "virtual": where it is mapped really depends on which view the > vCPU is running on. Using this feature allows us to hide the presence of > the breakpoints in a brand new way. To do this, first we create a complete > shadow copy of the memory page where a breakpoint is going to be written > and only write the breakpoint into this shadow copy. Now, using altp2m, we > setup a view where the guest physical memory of the page gets mapped to our > shadow copy. The guest continues to access its physical memory as before, > but underneath it is now using the trapped shadow copy. When the breakpoint > is hit, or if something is trying to scan the code, we simply switch the > view to the un-altered view for the duration of a singlestep, then switch > back to the trapped view. This allows us to hide the presence of the > breakpoints specific to each vCPU! All without having pause any of the > other vCPUs or having to emulate. The first open-source implementation of > this tracing has been already merged into the DRAKVUF Malware Analysis > System and is available as a reference implementation for those interested > in more details. > > As we can see, Xen continues to be on the forefront of advancing the > development of virtualization based security application and allowing > third-party tools to create some very exotic setups. This flexibility is > what's so great about Xen and why it will continue to be a trend-setter for > the foreseeable future. > > > Add a sub-headline: References > > [1] http://wiki.xenproject.org/wiki/Virtual_Machine_Introspection > [2] http://lists.xen.org/archives/html/xen-devel/2016-01/msg00285.html > [3] > https://blog.xenproject.org/2015/05/14/hardening-hypervisors-against-venom-style-attacks/ > [4] http://drakvuf.com > > > > > --047d7bf0d2d45c35240530600aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Lars,
I've fixed some mino= r things and it looks good now!

Thanks,
Tamas

On Wed, Apr 13,= 2016 at 9:59 AM, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
Draft blog at=C2=A0https://blog.xenproject.org/?p=3D11282= &preview=3Dtrue

@Tamas
Please do a qui= ck sanity check and let me know whether to publish. I also updated your bio= : if you want extra mods, let me know
Your account is linked to t= he above email address: you may want to reset the password

Lars

On 13 Apr 2= 016, at 16:24, Lars Kurth <lars.kurth.xen@gmail.com> wrote:

Tamas,

apologies. I miss= ed this in my inbox ...

I made a few minor suggest= ions: mainly shortening some sentences.=C2=A0
There are also a co= uple of questions

Do you want me to upload this to= the blog (under your username)? Where do you want to insert the png's?=

On 25 Jan 2016, at 20:51= , Lengyel, Tamas <tlengyel@novetta.com> wrote:

Hi all,
here is an updated version. Also, a couple pictures = that could be used as illustrations. Feel free to punch it up as needed ;)<= br>
Tamas

Stealthy monitoring = with Xen altp2m

One of the core features that differentiates Xen fro= m other open-source hypervisors is its native support for stealthy and secu= re monitoring of guest internals (aka. virtual machine introspection [1]). = In the latest release of Xen last summer

"In Xen 4.6 which was was released last autumn"
=

several new f= eatures have been introduced that make this subsystem better; a cleaned-up,= optimized API and ARM support being just some of the biggest items on this= list. As part of this release of Xen, a new and unique feature was also su= ccessfully added by a team from Intel that make stealthy monitoring even be= tter on Xen: altp2m. In this blog entry we will take a look at what it'= s all about.

In Xen's terminology, p2m stands for the memory man= agement layer that handles the translation from guest [p]hysical memory to = [m]achine physical. This translation is critical for safely partitioning th= e real memory of machine between Xen and the various VMs running as to ensu= re a VM can't simply access the memory of another. There are several im= plementations of this

There ar= e several implementations of this mechanism,

including one with hardware support via Inte= l Extended Page Tables (EPT) available to HVM (and PVH) guests
<= /div>

and PVH <guests>.

, called Hardwa= re Assisted Paging (hap) in Xen's terminology.

In Xen's terminology, this is called Hardwar= e Assisted Paging (hap).

In this implementation the hypervisor maintains a second page= table, similar to the one in 64-bit operating systems use, dedicated to run= ning the p2m translation. All (open-source) hypervisors that use this hardw= are assisted paging method use a single EPT per virtual machine to handle t= his translation, as most of the time the memory of the guest is assigned at= VM creation an doesn't change much afterwards.

Xen altp2m is th= e first implementation which changes this setup by allowing Xen to create m= ore then one EPT for each guest. Interestingly, the Intel hardware has been= capable of maintaining up to 512 EPT pointers in the VMCS since the first = introduction of EPT; however, noone made use of this capability until now. = This changed in Xen 4.6, where we can now create of up to 10 EPTs per guest= . The primary reason for this extension is of course the new #VE and VMFUNC= extensions that were released in the Skylake generation of CPUs (which is = worth a whole blog-entry on its own), but it can also be used by external m= onitoring applications via the Xen vm_event system.

It can also be used by external monitoring applic= ations via the Xen vm_event system.

Add a sub-head= line: Why alt2pm is a game-changer

=

Why this feature is a game-changer for appli= cations performing purely external monitoring is because it simplifies the = monitoring process of multi-vCPU guests.

Alt2pm is a game-changer for applications performing purely ext= ernal monitoring is because it simplifies the monitoring process of multi-v= CPU guests.

<= div>The EPT layer has been successfully used in stealthy monitoring applica= tions to track the memory accesses made by the VM from a safe vantage point= by restricting the type of access the VM may perform on various memory pag= es. Since EPT permission violations trap into the hypervisor, the VM would = receive no indication that anything out of the ordinary has happened. While= the method allowed for stealthy tracing of R/W/X memory accesses of the gu= est, the memory permission needs to be relaxed in order to allow the guest = to continue execution. When a single EPT is shared across multiple running = vCPUs, relaxing the permissions to allow one vCPU to continue may inadverta= ntly allow another one to perform the memory access we would otherwise want= to track. While under normal circumstances such race-condition may rarely = occur, malicious code could easily use this to hide some of its actions fro= m a monitoring application.

Solutions to this problem exist already.= For example we can pause all vCPUs while the one violating the access is s= inglestepped. This approach however introduces heavy overhead just to avoid= a race-condition that may rarely occur in practice. Alternatively, one cou= ld emulate the instruction that was violating the EPT permission without re= laxing the EPT access permissions, as Xen's built-in emulator doesn'= ;t use EPT to access the guest memory. This solution, while supported in Xe= n, is not particularly ideal either as Xen's emulator is incomplete and= is known to have issues that can lead to guest instability [2]. Furthermor= e, over the years emulation has been a hotbed of various security issues in= many hypervisors (including Xen [3]), thus building security tools based o= n emulation is simply asking for trouble. It can be handy but should be use= d only when no other option is available.

Xen's altp2m system ch= anges this problem quite significantly. By having multiple EPTs we can have= differing access permissions defined in each table, which can be easily sw= apped around by changing the active EPT index in the VMCS. When the guest m= akes a memory access that is monitored, instead of having to relax the acce= ss permission, Xen can simply switch to an EPT (called a view) that allows = the operation to continue. Afterwards the permissive view can be switched b= ack to the restriced view to continue monitoring. Since each vCPU has its o= wn VMCS where this switching is performed, this monitoring can be performed= specific to each vCPU, without having to pause any of the other ones, or h= aving to emulate the access. All without the guest noticing any of this swi= tching at all. A truly simple and elegant solution.


Add a sub-headline: Other introspection metho= ds for stealthy monitoring

Of course, EPT based monitoring is not the only introspe= cting technique used for stealthy monitoring. For example, the Xen based DR= AKVUF Dynamic Malware Analysis [4] uses it in combination with an additiona= l technique to maximum effect.

The main motivation for that is= because EPT based monitoring is known to introduce significant overhead, e= ven with altp2m: the granularity of the monitoring is that of a memory page= (4KB).

This sentence is = a bit convoluted and I lost you here. Not quite sure what you are trying to= say

If the = monitoring application is really just interested, for example, when a funct= ion-entry point is called, EPT based monitoring creates a lot of "fals= e" events when that page is accessed for the rest of the function'= s code.

Again, something seem= s to be missing here and I am struggling to understand =C2=A0what you are t= rying to say

=
Fortunately, this can be avoided by enabling the trapping of debug ins= tructions into the hypervisor, a built-in feature of Intel CPUs that Xen ex= poses to third-party applications. This method is used in DRAKVUF, which wr= ites breakpoint instructions into the guests' memory at code-locations = of interest. Since we will only get an event for precisely the code-locatio= n we are interested in this method effectively reduces the overhead. Howeve= r, the trade-off is that unlike EPT permissions the breakpoints are now vis= ible to the guest. Thus, to hide the presence of the breakpoints from the g= uest, these pages need to get further protected by restricting the pages to= be execute-only in the EPT. This allows DRAKVUF to remove the breakpoints = before in-guest code-integrity checking mechanisms (like Windows Patchguard= ) can access the page. While with altp2m the EPT permissions can be safely = used with multi-vCPU systems, using breakpoints similarly presents a race-c= ondition: the breakpoint hit by one vCPU has to be removed to allow the gue= st to execute the instruction that was originally overwritten, potentially = allowing another vCPU to do so as well without notice.

Fortunately, = altp2m has another neat feature that can be used to solve this problem. Bes= ide allowing for changing the memory permissions in the different altp2m vi= ews, it also allows to change the mapping itself! The same guest physical m= emory can be setup to be backed by different pages in the different views. = With this feature we can really thing of guest physical
<= /blockquote>

assuming: thing=3Dthink

memory as=C2=A0 "virtual&qu= ot;: where it is mapped really depends on which view the vCPU is running on= . Using this feature allows us to hide the presence of the breakpoints in a= brand new way. To do this, first=C2=A0 we create a complete shadow copy of= the memory page where a breakpoint is going to be written and only write t= he breakpoint into this shadow copy. Now, using altp2m, we setup a view whe= re the guest physical memory of the page gets mapped to our shadow copy. Th= e guest continues to access its physical memory as before, but underneath i= t is now using the trapped shadow copy. When the breakpoint is hit, or if s= omething is trying to scan the code, we simply switch the view to the un-al= tered view for the duration of a singlestep, then switch back to the trappe= d view. This allows us to hide the presence of the breakpoints specific to = each vCPU! All without having pause any of the other vCPUs or having to emu= late. The first open-source implementation of this tracing has been already= merged into the DRAKVUF Malware Analysis System and is available as a refe= rence implementation for those interested in more details.

As we can= see, Xen continues to be on the forefront of advancing the development of = virtualization based security application and allowing third-party tools to= create some very exotic setups. This flexibility is what's so great ab= out Xen and why it will continue to be a trend-setter for the foreseeable f= uture.


Add a sub-headl= ine: References




--047d7bf0d2d45c35240530600aa3-- --===============1939690588781400077== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============1939690588781400077==-- From publicity-bounces@lists.xenproject.org Wed Apr 13 16:32:27 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 16:32:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNiM-0005Zu-3J; Wed, 13 Apr 2016 16:32:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNiK-0005Z5-Gv for publicity@lists.xenproject.org; Wed, 13 Apr 2016 16:32:24 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 2C/8C-03281-7947E075; Wed, 13 Apr 2016 16:32:23 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRWlGSWpSXmKPExsXiVRtkqDu9hC/ cYMZfVovffWsZHRg9Dn+4whLAGMWamZeUX5HAmrHqaR9LwVHGilkLprE2MC5g7GLk4hASmMUo cW3HYhYQh0VgFqvE21tdzCCOhMA2VomJ3U+BMhxATozExgcWXYycQGalxNnGr0wgtpCAusS9R bfZISZ9Y5S4tx0iwSygJXHj30swm1dAT+LVrcusILawgI3EsZP3wGw2AW2JTTceMIPM5xQIlP jwJQckzCKgKrHm3mVGiDHFEo/fvGKHsLUlli18zQwx0kbi3fVGqA82s0ocWXqCDSQhIqAvMae zgQniUFmJ3b8fMU1gFJ6F5KRZSE6ahWTuAkbmVYzqxalFZalFuoZ6SUWZ6RkluYmZObqGhiZ6 uanFxYnpqTmJScV6yfm5mxiBgc4ABDsYj3Y6H2KU5GBSEuUVy+ULF+JLyk+pzEgszogvKs1JL T7EKMPBoSTBO7UYKCdYlJqeWpGWmQOMOZi0BAePkghvAkiat7ggMbc4Mx0idYrRkuPZtGtrmT gW/LgNJLdMvbeWSYglLz8vVUqctwqkQQCkIaM0D24cLC1cYpSVEuZlBDpQiKcgtSg3swRV/hW jOAejkjBvFsgUnsy8Eritr4AOYgI6qOwdL8hBJYkIKakGRlOFZ7LNV73mFt+7FXJ1U+J/gzdX wmyDjgos/B64cV/pkqXc5Vc7eZuuSGw2LP3CuZDhVUjLmxvaZ87avfvwvp1Xv9Xl4NSciqV6n eFKR3Y2r1VaJnGo012bp+0H97L4FUsDk7dfs/P8JDHV+4vliymfbtZGB4jFzsp+skDP1XzCQ3 63v5L/TyuxFGckGmoxFxUnAgAiRP2tBgMAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1460565142!35334641!1 X-Originating-IP: [74.125.82.49] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 42288 invoked from network); 13 Apr 2016 16:32:23 -0000 Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by server-9.tower-27.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 16:32:23 -0000 Received: by mail-wm0-f49.google.com with SMTP id a140so111159683wma.0 for ; Wed, 13 Apr 2016 09:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xsFpDJgm0vxl50OTU/0odV3EyOzV/vCW0YrFWRwxayQ=; b=QPXk5YWaSAKQ6RzI2cfo65HqFoTpUUE9ma4vDXJbjilX76kpSGg+yzLyfujlNN+A/V nEFD24QnCBVOIHx1p+TIofNxjLb7GFJnBIZ20T1CSvBrSjzRcXKs8EhUjbWIFLvMbqMm uMSMhpL/7D5RxQyR6wW0m4UeKpAzJ5nAhdyt0w6KG6qC7vZq5ZDnYNcdD0M7Ae+tqShX Mt79rzxkMB2uqZ3FfYphQGd+PUERg7EYYCyqDpEvsGj3uK0/riNdvvT7OUU7fA1Jqo0/ peCiBq2yZ80IVVVDuOhuLFuVycakdsa9K6xKhBqBgnnJB4w8nEVPtqUx929+snZC9jTt sXbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xsFpDJgm0vxl50OTU/0odV3EyOzV/vCW0YrFWRwxayQ=; b=dVXpxlwab0UOjPrOqsXzMkOe3Az7dSGmSkqffwVpYKevXXLgTTn9//kx+YjwGrt1SX myn4PdYow4FJsrsZXsTMJ7Y1L4xF60IQgrtZBoj0Wl3hIhW88jTLZl3ynx1gPqMNT1Ik nh6qN05wAjGTePZnYPyRivPFPrFg8clhwpgAgdwauIPm5GDlDIzzmntsfQxyH9+tubct +sUb7po8MGMMIVUYqyi3MfTmZsV19T3kNc6P7uEHao2Hpw88O7UVdGnStwNsmReiQ9l8 yH0FabpiEV697DS0XeOgxzEHHrTbHLVvyrSSgFbiZniDkuimOak6y5Rrfdas7mDaRLT/ fHsQ== X-Gm-Message-State: AOPr4FXrwdkXNuZcw+S7iuFdgcAagQkGtNr5SfgFGKiAx/Rn/35x0m7GuOx5bFqBdb7OUw== X-Received: by 10.194.6.225 with SMTP id e1mr11661636wja.152.1460565142747; Wed, 13 Apr 2016 09:32:22 -0700 (PDT) Received: from [192.168.0.12] (5ec0a29f.skybroadband.com. [94.192.162.159]) by smtp.gmail.com with ESMTPSA id d1sm25260245wjb.47.2016.04.13.09.32.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 09:32:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Wed, 13 Apr 2016 17:32:19 +0100 Message-Id: <61C0AC38-6AD7-4C89-A7BB-E19658CBC3F6@gmail.com> References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> To: Tamas K Lengyel X-Mailer: Apple Mail (2.2104) Cc: "publicity@lists.xenproject.org" Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" Cj4gT24gMTMgQXByIDIwMTYsIGF0IDE3OjEyLCBUYW1hcyBLIExlbmd5ZWwgPHRhbWFzLmsubGVu Z3llbEBnbWFpbC5jb20+IHdyb3RlOgo+IAo+IEhleSBMYXJzLAo+IEkndmUgZml4ZWQgc29tZSBt aW5vciB0aGluZ3MgYW5kIGl0IGxvb2tzIGdvb2Qgbm93IQo+IAo+IFRoYW5rcywKPiBUYW1hcwoK SXQncyBwdWJsaXNoZWQKTGFycwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpQdWJsaWNpdHkgbWFpbGluZyBsaXN0ClB1YmxpY2l0eUBsaXN0cy54ZW5wcm9q ZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3Rp bmZvL3B1YmxpY2l0eQo= From publicity-bounces@lists.xenproject.org Wed Apr 13 16:32:27 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 13 Apr 2016 16:32:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNiM-0005Zu-3J; Wed, 13 Apr 2016 16:32:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqNiK-0005Z5-Gv for publicity@lists.xenproject.org; Wed, 13 Apr 2016 16:32:24 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 2C/8C-03281-7947E075; Wed, 13 Apr 2016 16:32:23 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRWlGSWpSXmKPExsXiVRtkqDu9hC/ cYMZfVovffWsZHRg9Dn+4whLAGMWamZeUX5HAmrHqaR9LwVHGilkLprE2MC5g7GLk4hASmMUo cW3HYhYQh0VgFqvE21tdzCCOhMA2VomJ3U+BMhxATozExgcWXYycQGalxNnGr0wgtpCAusS9R bfZISZ9Y5S4tx0iwSygJXHj30swm1dAT+LVrcusILawgI3EsZP3wGw2AW2JTTceMIPM5xQIlP jwJQckzCKgKrHm3mVGiDHFEo/fvGKHsLUlli18zQwx0kbi3fVGqA82s0ocWXqCDSQhIqAvMae zgQniUFmJ3b8fMU1gFJ6F5KRZSE6ahWTuAkbmVYzqxalFZalFuoZ6SUWZ6RkluYmZObqGhiZ6 uanFxYnpqTmJScV6yfm5mxiBgc4ABDsYj3Y6H2KU5GBSEuUVy+ULF+JLyk+pzEgszogvKs1JL T7EKMPBoSTBO7UYKCdYlJqeWpGWmQOMOZi0BAePkghvAkiat7ggMbc4Mx0idYrRkuPZtGtrmT gW/LgNJLdMvbeWSYglLz8vVUqctwqkQQCkIaM0D24cLC1cYpSVEuZlBDpQiKcgtSg3swRV/hW jOAejkjBvFsgUnsy8Eritr4AOYgI6qOwdL8hBJYkIKakGRlOFZ7LNV73mFt+7FXJ1U+J/gzdX wmyDjgos/B64cV/pkqXc5Vc7eZuuSGw2LP3CuZDhVUjLmxvaZ87avfvwvp1Xv9Xl4NSciqV6n eFKR3Y2r1VaJnGo012bp+0H97L4FUsDk7dfs/P8JDHV+4vliymfbtZGB4jFzsp+skDP1XzCQ3 63v5L/TyuxFGckGmoxFxUnAgAiRP2tBgMAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1460565142!35334641!1 X-Originating-IP: [74.125.82.49] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 42288 invoked from network); 13 Apr 2016 16:32:23 -0000 Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by server-9.tower-27.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 13 Apr 2016 16:32:23 -0000 Received: by mail-wm0-f49.google.com with SMTP id a140so111159683wma.0 for ; Wed, 13 Apr 2016 09:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xsFpDJgm0vxl50OTU/0odV3EyOzV/vCW0YrFWRwxayQ=; b=QPXk5YWaSAKQ6RzI2cfo65HqFoTpUUE9ma4vDXJbjilX76kpSGg+yzLyfujlNN+A/V nEFD24QnCBVOIHx1p+TIofNxjLb7GFJnBIZ20T1CSvBrSjzRcXKs8EhUjbWIFLvMbqMm uMSMhpL/7D5RxQyR6wW0m4UeKpAzJ5nAhdyt0w6KG6qC7vZq5ZDnYNcdD0M7Ae+tqShX Mt79rzxkMB2uqZ3FfYphQGd+PUERg7EYYCyqDpEvsGj3uK0/riNdvvT7OUU7fA1Jqo0/ peCiBq2yZ80IVVVDuOhuLFuVycakdsa9K6xKhBqBgnnJB4w8nEVPtqUx929+snZC9jTt sXbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xsFpDJgm0vxl50OTU/0odV3EyOzV/vCW0YrFWRwxayQ=; b=dVXpxlwab0UOjPrOqsXzMkOe3Az7dSGmSkqffwVpYKevXXLgTTn9//kx+YjwGrt1SX myn4PdYow4FJsrsZXsTMJ7Y1L4xF60IQgrtZBoj0Wl3hIhW88jTLZl3ynx1gPqMNT1Ik nh6qN05wAjGTePZnYPyRivPFPrFg8clhwpgAgdwauIPm5GDlDIzzmntsfQxyH9+tubct +sUb7po8MGMMIVUYqyi3MfTmZsV19T3kNc6P7uEHao2Hpw88O7UVdGnStwNsmReiQ9l8 yH0FabpiEV697DS0XeOgxzEHHrTbHLVvyrSSgFbiZniDkuimOak6y5Rrfdas7mDaRLT/ fHsQ== X-Gm-Message-State: AOPr4FXrwdkXNuZcw+S7iuFdgcAagQkGtNr5SfgFGKiAx/Rn/35x0m7GuOx5bFqBdb7OUw== X-Received: by 10.194.6.225 with SMTP id e1mr11661636wja.152.1460565142747; Wed, 13 Apr 2016 09:32:22 -0700 (PDT) Received: from [192.168.0.12] (5ec0a29f.skybroadband.com. [94.192.162.159]) by smtp.gmail.com with ESMTPSA id d1sm25260245wjb.47.2016.04.13.09.32.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 09:32:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Wed, 13 Apr 2016 17:32:19 +0100 Message-Id: <61C0AC38-6AD7-4C89-A7BB-E19658CBC3F6@gmail.com> References: <568AA198.8000308@bitdefender.com> <568ACF08.1070905@bitdefender.com> <90C49EB6-4611-43F5-BD9A-82CBD5BCA300@gmail.com> <506C6432-96D8-480A-9740-C422C2D6789E@gmail.com> <1C46D325-31AA-4FAB-A512-612103297025@gmail.com> To: Tamas K Lengyel X-Mailer: Apple Mail (2.2104) Cc: "publicity@lists.xenproject.org" Subject: Re: [Publicity] Stealthy monitoring with Xen altp2m X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" Cj4gT24gMTMgQXByIDIwMTYsIGF0IDE3OjEyLCBUYW1hcyBLIExlbmd5ZWwgPHRhbWFzLmsubGVu Z3llbEBnbWFpbC5jb20+IHdyb3RlOgo+IAo+IEhleSBMYXJzLAo+IEkndmUgZml4ZWQgc29tZSBt aW5vciB0aGluZ3MgYW5kIGl0IGxvb2tzIGdvb2Qgbm93IQo+IAo+IFRoYW5rcywKPiBUYW1hcwoK SXQncyBwdWJsaXNoZWQKTGFycwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpQdWJsaWNpdHkgbWFpbGluZyBsaXN0ClB1YmxpY2l0eUBsaXN0cy54ZW5wcm9q ZWN0Lm9yZwpodHRwOi8vbGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3Rp bmZvL3B1YmxpY2l0eQo= From publicity-bounces@lists.xenproject.org Fri Apr 22 18:48:39 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 Apr 2016 18:48:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg85-00078k-Io; Fri, 22 Apr 2016 18:48:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg84-00078b-Gq for publicity@lists.xenproject.org; Fri, 22 Apr 2016 18:48:36 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id E4/5E-01795-3027A175; Fri, 22 Apr 2016 18:48:35 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRWlGSWpSXmKPExsXiVRtkrMtUJBV u0LXP0uJ331pGB0aPwx+usAQwRrFm5iXlVySwZhzqPs1cMIm5ouHJCvYGxgtMXYxcHEICMxgl fm18wAzisAg0s0pcnbMWKMPJISEwn1Xi75bILkYOIDtGYuI0F4hwucTHdStYQGwhAXWJe4tus 0MM+sooMb/vIjtIgk1AW2LTDZChnBzMAloSN/69ZIKwtSWWLXzNDDJTWCBO4vczK5Awi4CqRO fh7+wgYV4BG4kLU+NBRjILrGGUuL74CNihIgKzGCU6mhrBFvMK6Em8unWZFeIgWYndvx8xTWA UnIVk3Swk62YhaVnAyLyKUaM4tagstUjX0FAvqSgzPaMkNzEzR9fQwFQvN7W4ODE9NScxqVgv OT93EyMwcBmAYAfjynbnQ4ySHExKorxeIVLhQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4OwuAc oJFqempFWmZOcAYgklLcPAoifCeAknzFhck5hZnpkOkTjEacyz4cXstE8eWqffWMgmx5OXnpU qJ89qDlAqAlGaU5sENgsX2JUZZKWFeRqDThHgKUotyM0tQ5V8xinMwKgnzngeZwpOZVwK37xX QKUxAp/y7IAlySkkiQkqqgdGL92Pp7h2Vt/U5m/X/lHdP4N617v1Mv5a/M5KzV+9ScelpaH0U bCoe78emvtVs1fyWoCfi5QVPxDtFDhdZrpjzT3rTF8etz9ubnqhU5h07IDv7+yqdkKiXze7P5 G/br427JZj3LI43N9Bafq+jmNmPZzvmRiuJ/HS6+0QkuGmp6XzZ7PzybiWW4oxEQy3mouJEAA R3azboAgAA X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1461350914!3318039!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 60945 invoked from network); 22 Apr 2016 18:48:34 -0000 Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by server-14.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 22 Apr 2016 18:48:34 -0000 Received: by mail-wm0-f51.google.com with SMTP id v200so4042051wmv.1 for ; Fri, 22 Apr 2016 11:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=5yhYlC/1UmGwyJc3W3FIf2DdYor9Jp1q0dHzAmJGJgI=; b=lO3iW8JhpBhG94KmYqg/zXrfM7Ac7B3e/qwytf5uqI2W9IHOWMkZnbqgyL9n7zicYx TKMogNCOu3FBDhBIcVS4iqZODHF5FgNDnwPBFC303YDMKPw/qrtZXKg8J/bHaQDwJMM2 XlE4ox32Atori1a7NbzX7zRstBE7T5I1FXIrmNzPW18N8c82vSwFJCbyHKG7eDC74kAk BjS92P4C2QoTGGuwkw9oPOA24h99ZB7bW0b8IFzGmVL/2ACEbgjfiSs9V541S5aNu9k9 W9I6jBP9qGd9LeYMDx5u6DvVgwDNEcC+IYuMpXjYK4/1kCLu/Us9niP3GisIiMBrZPgN LIUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=5yhYlC/1UmGwyJc3W3FIf2DdYor9Jp1q0dHzAmJGJgI=; b=Ju/XOfuCZK9+K+HHzQox2EnKElKeHeDvm7KAiXlyzJfshqApL33jCaPmRzNwEUuohU 54a28FEEEc3KV74CEDJuk5D5ZRoXpEvZMq657LFN6639+Y3EWV/wp0MsREWF4sC8xbTM bhT9HDXjjuEZUvtv9SSnZ49MtYaY6ljwP8v08gNsVO18Zzw2OzzjUbb10WYqdxHdH/Zw vlPKZ0o1MMefcUUsiJZLdOxyKlNK0uxmVJyMBKfu0eYAvwnBbq40ZONhYDA50ycJGM1O 34QP1K6aVjjZgWLzi4f1C+z8lHx5BI3X/e3KvEd1YMUouquPml8nBzUzJGGT+ffOUxQE tNhA== X-Gm-Message-State: AOPr4FUrUwmTNbT7qPdaBF++P/9wwgC2Ux8oSzFiHXsu5cyhNAW7EFnnvpy41ptwD9uCrg== X-Received: by 10.28.230.137 with SMTP id e9mr5688751wmi.0.1461350914583; Fri, 22 Apr 2016 11:48:34 -0700 (PDT) Received: from [192.168.0.12] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id gr4sm9371649wjd.23.2016.04.22.11.48.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 11:48:33 -0700 (PDT) From: Lars Kurth Date: Fri, 22 Apr 2016 19:48:32 +0100 Message-Id: To: publicity@lists.xenproject.org, appointments@xenproject.org, Sarah Conway , Zibby Keaton Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , Andrew Cooper , George Dunlap , sstabellini@kernel.org Subject: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" U2VlIGh0dHBzOi8vYmxvZy54ZW5wcm9qZWN0Lm9yZy8/cD0xMTMxMCZwcmV2aWV3PXRydWUKSSB3 b3VsZCBsaWtlIHRvIHB1Ymxpc2ggb24gTW9uZGF5CgpUaG9zZSBvbiB0aGUgQ0MgbGlzdDogSSBt YWRlIHVwIHNvbWUgc2hvcnQgYmlvcyBmb3IgZWFjaCBvZiB5b3UsIGJhc2VkIG9uIHdoYXQgSSBr bm93LiBGZWVsIGZyZWUgdG8gc3VnZ2VzdCBjb3JyZWN0aW9ucy9hZGRpdGlvbnMuCgpAWmliYnk6 IGNvdWxkIHlvdSBnbyB0aHJvdWdoIHRoaXMgd2l0aCBhIHZpZXcgdG93YXJkcyBtZWRpYSBpbXBh Y3QgKGUuZy4gYSBwb3NzaWJseSBuZWdhdGl2ZSByZWdpc3RlciBzdG9yeSkuIFdlIGFyZSBpbnRl bnRpb25hbGx5IG5vdCBzdGF0aW5nIGNvbXBhbnkgYWZmaWxpYXRpb24uCgpMYXJzCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClB1YmxpY2l0eSBtYWlsaW5n IGxpc3QKUHVibGljaXR5QGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9q ZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vcHVibGljaXR5Cg== From publicity-bounces@lists.xenproject.org Fri Apr 22 18:48:39 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 Apr 2016 18:48:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg85-00078k-Io; Fri, 22 Apr 2016 18:48:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg84-00078b-Gq for publicity@lists.xenproject.org; Fri, 22 Apr 2016 18:48:36 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id E4/5E-01795-3027A175; Fri, 22 Apr 2016 18:48:35 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRWlGSWpSXmKPExsXiVRtkrMtUJBV u0LXP0uJ331pGB0aPwx+usAQwRrFm5iXlVySwZhzqPs1cMIm5ouHJCvYGxgtMXYxcHEICMxgl fm18wAzisAg0s0pcnbMWKMPJISEwn1Xi75bILkYOIDtGYuI0F4hwucTHdStYQGwhAXWJe4tus 0MM+sooMb/vIjtIgk1AW2LTDZChnBzMAloSN/69ZIKwtSWWLXzNDDJTWCBO4vczK5Awi4CqRO fh7+wgYV4BG4kLU+NBRjILrGGUuL74CNihIgKzGCU6mhrBFvMK6Em8unWZFeIgWYndvx8xTWA UnIVk3Swk62YhaVnAyLyKUaM4tagstUjX0FAvqSgzPaMkNzEzR9fQwFQvN7W4ODE9NScxqVgv OT93EyMwcBmAYAfjynbnQ4ySHExKorxeIVLhQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4OwuAc oJFqempFWmZOcAYgklLcPAoifCeAknzFhck5hZnpkOkTjEacyz4cXstE8eWqffWMgmx5OXnpU qJ89qDlAqAlGaU5sENgsX2JUZZKWFeRqDThHgKUotyM0tQ5V8xinMwKgnzngeZwpOZVwK37xX QKUxAp/y7IAlySkkiQkqqgdGL92Pp7h2Vt/U5m/X/lHdP4N617v1Mv5a/M5KzV+9ScelpaH0U bCoe78emvtVs1fyWoCfi5QVPxDtFDhdZrpjzT3rTF8etz9ubnqhU5h07IDv7+yqdkKiXze7P5 G/br427JZj3LI43N9Bafq+jmNmPZzvmRiuJ/HS6+0QkuGmp6XzZ7PzybiWW4oxEQy3mouJEAA R3azboAgAA X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1461350914!3318039!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 60945 invoked from network); 22 Apr 2016 18:48:34 -0000 Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by server-14.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 22 Apr 2016 18:48:34 -0000 Received: by mail-wm0-f51.google.com with SMTP id v200so4042051wmv.1 for ; Fri, 22 Apr 2016 11:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=5yhYlC/1UmGwyJc3W3FIf2DdYor9Jp1q0dHzAmJGJgI=; b=lO3iW8JhpBhG94KmYqg/zXrfM7Ac7B3e/qwytf5uqI2W9IHOWMkZnbqgyL9n7zicYx TKMogNCOu3FBDhBIcVS4iqZODHF5FgNDnwPBFC303YDMKPw/qrtZXKg8J/bHaQDwJMM2 XlE4ox32Atori1a7NbzX7zRstBE7T5I1FXIrmNzPW18N8c82vSwFJCbyHKG7eDC74kAk BjS92P4C2QoTGGuwkw9oPOA24h99ZB7bW0b8IFzGmVL/2ACEbgjfiSs9V541S5aNu9k9 W9I6jBP9qGd9LeYMDx5u6DvVgwDNEcC+IYuMpXjYK4/1kCLu/Us9niP3GisIiMBrZPgN LIUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=5yhYlC/1UmGwyJc3W3FIf2DdYor9Jp1q0dHzAmJGJgI=; b=Ju/XOfuCZK9+K+HHzQox2EnKElKeHeDvm7KAiXlyzJfshqApL33jCaPmRzNwEUuohU 54a28FEEEc3KV74CEDJuk5D5ZRoXpEvZMq657LFN6639+Y3EWV/wp0MsREWF4sC8xbTM bhT9HDXjjuEZUvtv9SSnZ49MtYaY6ljwP8v08gNsVO18Zzw2OzzjUbb10WYqdxHdH/Zw vlPKZ0o1MMefcUUsiJZLdOxyKlNK0uxmVJyMBKfu0eYAvwnBbq40ZONhYDA50ycJGM1O 34QP1K6aVjjZgWLzi4f1C+z8lHx5BI3X/e3KvEd1YMUouquPml8nBzUzJGGT+ffOUxQE tNhA== X-Gm-Message-State: AOPr4FUrUwmTNbT7qPdaBF++P/9wwgC2Ux8oSzFiHXsu5cyhNAW7EFnnvpy41ptwD9uCrg== X-Received: by 10.28.230.137 with SMTP id e9mr5688751wmi.0.1461350914583; Fri, 22 Apr 2016 11:48:34 -0700 (PDT) Received: from [192.168.0.12] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id gr4sm9371649wjd.23.2016.04.22.11.48.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 11:48:33 -0700 (PDT) From: Lars Kurth Date: Fri, 22 Apr 2016 19:48:32 +0100 Message-Id: To: publicity@lists.xenproject.org, appointments@xenproject.org, Sarah Conway , Zibby Keaton Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , Andrew Cooper , George Dunlap , sstabellini@kernel.org Subject: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" U2VlIGh0dHBzOi8vYmxvZy54ZW5wcm9qZWN0Lm9yZy8/cD0xMTMxMCZwcmV2aWV3PXRydWUKSSB3 b3VsZCBsaWtlIHRvIHB1Ymxpc2ggb24gTW9uZGF5CgpUaG9zZSBvbiB0aGUgQ0MgbGlzdDogSSBt YWRlIHVwIHNvbWUgc2hvcnQgYmlvcyBmb3IgZWFjaCBvZiB5b3UsIGJhc2VkIG9uIHdoYXQgSSBr bm93LiBGZWVsIGZyZWUgdG8gc3VnZ2VzdCBjb3JyZWN0aW9ucy9hZGRpdGlvbnMuCgpAWmliYnk6 IGNvdWxkIHlvdSBnbyB0aHJvdWdoIHRoaXMgd2l0aCBhIHZpZXcgdG93YXJkcyBtZWRpYSBpbXBh Y3QgKGUuZy4gYSBwb3NzaWJseSBuZWdhdGl2ZSByZWdpc3RlciBzdG9yeSkuIFdlIGFyZSBpbnRl bnRpb25hbGx5IG5vdCBzdGF0aW5nIGNvbXBhbnkgYWZmaWxpYXRpb24uCgpMYXJzCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClB1YmxpY2l0eSBtYWlsaW5n IGxpc3QKUHVibGljaXR5QGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHA6Ly9saXN0cy54ZW5wcm9q ZWN0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vcHVibGljaXR5Cg== From publicity-bounces@lists.xenproject.org Fri Apr 22 18:49:54 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 Apr 2016 18:49:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg9K-0007Kf-Mr; Fri, 22 Apr 2016 18:49:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg9J-0007KI-Mw for publicity@lists.xenproject.org; Fri, 22 Apr 2016 18:49:53 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 68/E2-18387-1527A175; Fri, 22 Apr 2016 18:49:53 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRWlGSWpSXmKPExsXiVRtkoBtQJBV u8O49o8XvvrWMDowehz9cYQlgjGLNzEvKr0hgzbh/+wx7wQGlit9rpzM3MF6R6WLk4hASmM4o cW3zRTYQh0VgFqtER+N6IIeTQ0JgG6vEiWtmEHaMxIY395i6GDmA7AqJ1ZcqQcJCAuoS9xbdZ ocY9IVR4vKLs0wgCWagxJ95l5hBbF4BPYlXty6zgtjCAkkSz67+YASx2QS0JTbdeMAMMpNTwF ZiypFKEJNFQFWicaEFyEhmgTWMEtcXH4EaqS2xbOFrsHJeARuJpg0cECfYSDxcuZEVpF5EYBa jREdTIwvEybISu38/YprAKDwLyUWzkFw0C8nYBYzMqxjVi1OLylKLdC31kooy0zNKchMzc3QN DUz1clOLixPTU3MSk4r1kvNzNzECg5wBCHYwrm11PsQoycGkJMrrFSIVLsSXlJ9SmZFYnBFfV JqTWnyIUYaDQ0mCd1UhUE6wKDU9tSItMwcYbzBpCQ4eJRHeBpA0b3FBYm5xZjpE6hSjLseWqf fWMgmx5OXnpUqJ8x4AKRIAKcoozYMbAYv9S4yyUsK8jEBHCfEUpBblZpagyr9iFOdgVBLm9Qa ZwpOZVwK36RXQEUxAR/y7IAlyREkiQkqqgZFZ5NYJy5y+jFMbgvWep6ovEbxy8W3QyaUZj3aq HJRb8EuB4+66dV8SDRpKDsZE24S9v/hzyszEAEO/tq+VsnkcMzOu9UxQFPR1cpDtODClrZn9W ++d7jqmT+mvdqUqiiT6bDn89m51sZORieHH6xNLRTfsXzTfuzpA8NCnRZKnP6o8L1jDoaPEUp yRaKjFXFScCADo4Uvc+AIAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1461350991!18808645!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 61764 invoked from network); 22 Apr 2016 18:49:52 -0000 Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by server-10.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 22 Apr 2016 18:49:52 -0000 Received: by mail-wm0-f48.google.com with SMTP id n3so40069807wmn.0 for ; Fri, 22 Apr 2016 11:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z6I8zd4GeccOYbyYUc6/NeHiRmN5S4Jx9LCLbOkXF5s=; b=wQzRyak42iso61zU4Z1Plxnowl+1SUbbmGaX6jcRfI/08Ccddws3WmJZj9pXYdNUNO HhsNNeO7cLsPlORfGfxDBBqwVYx+0ILdsENEEQ8P7K1IDeZrhskC5M+MlefOu0fOdm79 uqUFLSD+YY2g3wQYMW5jKC8pFvdnJeKHFdZ34b37gILEfY8VnXgvVpulIoH472mly6aC SUXjar25sj291Bmo/mz2OAhrRpUkezzMuL2hoiZgqSzxex2Q5KS0La20Z6OXNQHFbhzm sxqWhfvaipWhkvBLVTX+ouayYdLoLkRoqnxvykAP87eROtUxDgrajtUwJMOiWMD2RX9O wyHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z6I8zd4GeccOYbyYUc6/NeHiRmN5S4Jx9LCLbOkXF5s=; b=eKmgYzOL9z8d5hre4sMeSYmkqcJ9aA/i53nZIUcxg5naEmleV/VWlkE38CRpagAoHy rIgmBuOLYZXzsAvhf1jpBv4lmzwDGsdZs1euiO7eQGXyB6vHmcVLLdVTjSzRwGz1cZkp ftB7zfhHwps9HbxfZOXwSPAXlT12NvIb1xqbNBkegORmxeD8YKSpXwnlKKieLGkihd5N A+l03YJFTdoItuH2Ot1K66S8r5cPHIHDmb/OSo920ssU4eXS5exM/8xv1KM+E3OmWEGT J/JzPZe1MDBovp5jbJEQhvl4gvpbooraJ56es6AwoOKd7EDvyAhBkXwEjUMDEbipapex l0Ng== X-Gm-Message-State: AOPr4FXcSfpg23/V8VRPWEO+tkvLOSYkFarBtzeDdz/uFjpO4BCrWhvcxr8MuJrKUceDOw== X-Received: by 10.28.92.69 with SMTP id q66mr5655256wmb.102.1461350991717; Fri, 22 Apr 2016 11:49:51 -0700 (PDT) Received: from [192.168.0.12] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id u3sm4640249wmg.15.2016.04.22.11.49.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 11:49:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Fri, 22 Apr 2016 19:49:50 +0100 Message-Id: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> References: To: publicity@lists.xenproject.org, appointments@xenproject.org, Sarah Conway , Zibby Keaton X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , Andrew Cooper , George Dunlap , sstabellini@kernel.org Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" Cj4gT24gMjIgQXByIDIwMTYsIGF0IDE5OjQ4LCBMYXJzIEt1cnRoIDxsYXJzLmt1cnRoLnhlbkBn bWFpbC5jb20+IHdyb3RlOgo+IAo+IFNlZSBodHRwczovL2Jsb2cueGVucHJvamVjdC5vcmcvP3A9 MTEzMTAmcHJldmlldz10cnVlCj4gSSB3b3VsZCBsaWtlIHRvIHB1Ymxpc2ggb24gTW9uZGF5Cj4g Cj4gVGhvc2Ugb24gdGhlIENDIGxpc3Q6IEkgbWFkZSB1cCBzb21lIHNob3J0IGJpb3MgZm9yIGVh Y2ggb2YgeW91LCBiYXNlZCBvbiB3aGF0IEkga25vdy4gRmVlbCBmcmVlIHRvIHN1Z2dlc3QgY29y cmVjdGlvbnMvYWRkaXRpb25zLgo+IAo+IEBaaWJieTogY291bGQgeW91IGdvIHRocm91Z2ggdGhp cyB3aXRoIGEgdmlldyB0b3dhcmRzIG1lZGlhIGltcGFjdCAoZS5nLiBhIHBvc3NpYmx5IG5lZ2F0 aXZlIHJlZ2lzdGVyIHN0b3J5KS4gV2UgYXJlIGludGVudGlvbmFsbHkgbm90IHN0YXRpbmcgY29t cGFueSBhZmZpbGlhdGlvbi4KPiAKPiBMYXJzCgoKSSBhZGRlZCB0aGUgdGV4dCAodW5mb3JtYXR0 ZWQpIGZvciBjb252ZW5pZW5jZQpMYXJzCgotLS0KCkEgY291cGxlIG9mIG1vbnRocyBhZ28gdHdv IG9mIG91ciBjb21taXR0ZXJzLCBLZWlyIEZyYXNlciBhbmQgVGltIERlZWdhbiwgaGF2ZSBmb3Jt YWxseSBzdGVwcGVkIGRvd24gaW4gdGhlaXIgcm9sZXMgYXMgY29tbWl0dGVycyBmcm9tIHRoZSBI eXBlcnZpc29yIHRlYW0sIHdoaWxlIG90aGVycyBoYXZlIGNoYW5nZWQgdGhlaXIgZm9jdXMgb3Ig bGV2ZWwgb2YgaW52b2x2ZW1lbnQgaW4gdGhlIHByb2plY3QuClVuZm9ydHVuYXRlbHksIHRoZSBw cm9qZWN0IGhhcyBmb3VuZCBpdCBkaWZmaWN1bHQgdG8gcHJvbW90ZSBjb250cmlidXRvcnMgdG8g bWFpbnRhaW5lciBhbmRjb21taXR0ZXIgcm9sZXMsIHdoaWNoIGNvbnN0aXR1dGUgdGhlIGxlYWRl cnNoaXAgb2YgdGhlIFhlbiBQcm9qZWN0IEh5cGVydmlzb3IgVGVhbS4gVGhpcyB3YXMgdHJ1ZSwg ZGVzcGl0ZSBhbiBhY3RpdmVseSBncm93aW5nIGNvbW11bml0eSAoc2VlIGRpYWdyYW0gb24gdGhl IHJpZ2h0KS4KCkFmdGVyIHNvbWUgc291bCBzZWFyY2hpbmcsIHdlIHJlYWxpc2VkIHRoYXQgdGhl IHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGlzc3VlIHdhcyBub3QgdGhhdCB3ZSBkaWRu4oCZdCBo YXZlIGZ1dHVyZSBsZWFkZXJzIHdpdGhpbiB0aGUgY29tbXVuaXR5LiBUaGUgaXNzdWUgd2FzIHNp bXBseSB0aGF0IHdlIGRpZG7igJl0IGhhdmUgYW4gb3JnYW5pc2VkIGFwcHJvYWNoIHRvIHN1Y2Nl c3Npb24gcGxhbm5pbmc6IGFjdGl2ZSBkZXZlbG9wZXJzIHNpbXBseSB3b3JrZWQgb24gdGhlIHBy b2plY3QgYW5kIGRpZCBub3QgY29uc2lkZXIgdG8gbm9taW5hdGUgbmV3Y29tZXJzIChvciB0aGVt c2VsdmVzKSBmb3IgbGVhZGVyc2hpcCByb2xlcyB3aXRoaW4gdGhlIHByb2plY3QuIFRvIGZpeCB0 aGlzLCB3ZSBpbnRyb2R1Y2VkIGEgbmV3IGNvbnZlbnRpb24sIGJ5IHdoaWNoIHdlIGFjdGl2ZWx5 IHJlbWluZCBjb21tdW5pdHkgbWVtYmVycyB0byBub21pbmF0ZSBvciBzZWxmLW5vbWluYXRlIHRo ZW1zZWx2ZXMgZm9yIGxlYWRlcnNoaXAgcm9sZXMuCgpUaGlzIGFwcHJvYWNoIGhhcyB3b3JrZWQg dmVyeSB3ZWxsLCBhbmQgSSBhbSBwbGVhc2VkIHRvIGFubm91bmNlIHRoZSBmb2xsb3dpbmcgbmV3 IG1lbWJlcnMgdG8gdGhlIFhlbiBQcm9qZWN0IEh5cGVydmlzb3IgTGVhZGVyc2hpcCBUZWFtLiBI b3dldmVyLCBiZWZvcmUgZG9pbmcgc28sIEkgd2FudGVkIHRvIHRoYW5rIEtlaXIgYW5kIFRpbSBm b3IgdGhlaXIgdmFzdCBjb250cmlidXRpb25zIHRvIHRoZSBwcm9qZWN0LgoKQ29tbWl0dGVycwoK VGhlIGZvbGxvd2luZyBwZW9wbGUgaGF2ZSBiZWVuIGVsZWN0ZWQgdG8gYmUgbmV3IENvbW1pdHRl cnMgdG8gdGhlIHByb2plY3QsIGFsb25nc2lkZSBJYW4gQ2FtcGJlbGwsIElhbiBKYWNrc29uLCBK YW4gQmV1bGljaCBhbmQgS29ucmFkIFJ6ZXN6dXRlayBXaWxrOgoKQW5kcmV3IENvb3BlciBoYXMg YmVlbiB3b3JraW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMTEgYW5kIGhhcyBhZGRlZCBh IG51bWJlciBvZiBtYWpvciBuZXcgZmVhdHVyZXMgc3VjaCBhcyBNaWdyYXRpb24gdjIsIHNpZ25p ZmljYW50IGNoYW5nZSB0byB0cmFwIGhhbmRsaW5nLCBpbXByb3ZlbWVudHMgdG8gY3B1aWQgaGFu ZGxpbmcgZm9yIGd1ZXN0cyBhbmQgbWFueSBtb3JlLgoKR2VvcmdlIER1bmxhcCBoYXMgYmVlbiB3 b3JraW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMDggYW5kIHdhcyBoZWF2aWx5IGludm9s dmVkIGluIG1ha2luZyB0aGUgdHJhY2luZyBzeXN0ZW0gdXNlYWJsZSBmb3IKcGVyZm9ybWFuY2Ug YW5hbHlzaXMsIG9wdGltaXNpbmcgdGhlIHNoYWRvdyBjb2RlLCB3cm90ZSB0aGUgY3JlZGl0MiBz Y2hlZHVsZXIgYW5kIGRldmVsb3BlZCBtYW55IG90aGVyIHNpZ25pZmljYW50IGZlYXR1cmVzIGFu ZCBpbXByb3ZlbWVudHMgaW4gdGhlIGh5cGVydmlzb3IuIEluIGFkZGl0aW9uLCBoZSB3YXMgb3Vy IGZpcnN0IFJlbGVhc2UgTWFuYWdlciBhbmQgaXMgbGVhZGluZyB0aGUgQ2VudE9TIFZpcnR1YWxp c2F0aW9uIFNJRyB3aXRoaW4gQ2VudE9TLgoKU3RlZmFubyBTdGFiZWxsaW5pIGhhcyBiZWVuIHdv cmtpbmcgb24gdGhlIEh5cGVydmlzb3IgYW5kIHRoZSBMaW51eCBLZXJuZWwgc2luY2UgMjAwOCBh bmQgd2FzIGluc3RydW1lbnRhbCBpbiBicmluZ2luZyBBUk0gc3VwcG9ydCB0byB0aGUgWGVuIEh5 cGVydmlzb3IuIEhlIGhhcyBhbHNvIGJlZW4gbGVhZGluZyBtYW55IG90aGVyIGFjdGl2aXRpZXMg d2l0aGluIHRoZSBwcm9qZWN0LCBzdWNoIGFzIE9wZW5TdGFjayBpbnRlZ3JhdGlvbiBhbmQgUmFp c2luLgoKV2VpIExpdSBzdGFydGVkIHRvIHdvcmsgb24gdGhlIFhlbiBQcm9qZWN0IGFzIGEgR1Nv QyBzdHVkZW50IGluIDIwMTEgKHdvcmtpbmcgaW4gdmlydGlvIHN1cHBvcnQpLiBIZSBoYXMgYmVl biB3b3JraW5nIG9uIGxpYnhsIHN1cHBvcnQsIGV2ZW50IGNoYW5uZWwgc2NhbGFiaWxpdHksIE1p bmlPUyBhbmQgbWFueSBvdGhlciBtYWpvciBYZW4gZmVhdHVyZXMuIEluIGFkZGl0aW9uIGhlIGhh cyBiZWVuIHRoZSBYZW4gUHJvamVjdCBSZWxlYXNlIE1hbmFnZXIgc2luY2UgWGVuIFByb2plY3Qg NC42IHJlbGVhc2UuCgpBbmRyZXcgYW5kIFdlaSBjZWxlYnJhdGVkIHRoZWlyIGFwcG9pbnRtZW50 IGF0IG9uZSBvZiB0aGUgWGVuIFByb2plY3Qgc29jaWFsIGV2ZW50cyBlYXJsaWVyIHRoaXMgd2Vl aywgYnkgc3VibWl0dGluZyBhbmQgQUNLaW5nIGEgcGllY2Ugb2YgY29kZSB3aGlsZSBvbiBhIHB1 bnQgb24gdGhlIHJpdmVyIENhbSBpbiBDYW1icmlkZ2UsIFVLLgoKClNlY3VyaXR5IFRlYW0KCklu IGFkZGl0aW9uLCBBbmRyZXcgQ29vcGVyIGFuZCBHZW9yZ2UgRHVubGFwIGFyZSBub3cgYWxzbyBt ZW1iZXJzIG9mIHRoZSBYZW4gUHJvamVjdCBTZWN1cml0eSBUZWFtLCBhbG9uZ3NpZGUgSWFuIEph Y2tzb24sIEphbiBCZXVsaWNoIGFuZCBUaW0gRGVlZ2FuLgoKTWFpbnRhaW5lcnMKClRoZSBmb2xs b3dpbmcgcGVvcGxlIHdlcmUgYWxzbyByZWNlbnRseSBhZGRlZCBhcyBNQUlOVEFJTkVSUyBvZiB0 aGUgcHJvamVjdDogRG91ZyBHb2xkc3RlaW4oS0NvbmZpZywgVHJhdmlzIENJKSwgSnVsaWVuIEdy YWxsIChBUk0gc3VwcG9ydCwgZGV2aWNlIHRyZWUsIOKApiksIE1lbmcgWHUgKFJURFMgU2NoZWR1 bGVyKSBhbmRQYXVsIER1cnJhbnQgKHg4NiBJL08gZW11bGF0aW9uLCB4ODYgdmlyaWRpYW4gZW5s aWdodGVubWVudHMsIOKApikuIEluIGFkZGl0aW9uLCB3ZSBjbGFyaWZpZWQgc29tZSBhbWJpZ3Vp dGllcyBhcm91bmQgdGhlIG1haW50YWluZXIgcm9sZS4KCkxpbnV4IEtlcm5lbCBNYWludGFpbmVy cwoKSsO8cmdlbiBHcm9zcyB3aG8gaGFzIGJlZW4gYSBMaW51eCBrZXJuZWwgYW5kIFhlbiBkZXZl bG9wZXIgc2luY2UgMjAwNCwgYnV0IGhhcyBzaWduaWZpY2FudGx5IGluY3JlYXNlZCBoaXMgZW5n YWdlbWVudCB3aXRoaW4gdGhlIGNvbW11bml0eSBpbiB0aGUgbGFzdCB0d28geWVhcnMsIGFuZCBp cyBub3cgTGludXggS2VybmVsIG1haW50YWluZXIgZm9yIHRoZSBYZW4gSHlwZXJ2aXNvciBJbnRl cmZhY2UgYWxvbmdzaWRlIEJvcmlzIE9zdHJvdnNreSBhbmQgRGF2aWQgVnJhYmVsLiBPdGhlciBt YWludGFpbmVycyBvZiBYZW4gc3BlY2lmaWMgY29tcG9uZW50cyBpbiB0aGUgTGludXggS2VybmVs IGFyZTogU3RlZmFubyBTdGFiZWxsaW5pLCBXZWkgTHVpLCBhbmQgS29ucmFkIFJ6ZXN6dXRlayBX aWxrLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpQdWJs aWNpdHkgbWFpbGluZyBsaXN0ClB1YmxpY2l0eUBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8v bGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL3B1YmxpY2l0eQo= From publicity-bounces@lists.xenproject.org Fri Apr 22 18:49:54 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 Apr 2016 18:49:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg9K-0007Kf-Mr; Fri, 22 Apr 2016 18:49:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atg9J-0007KI-Mw for publicity@lists.xenproject.org; Fri, 22 Apr 2016 18:49:53 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 68/E2-18387-1527A175; Fri, 22 Apr 2016 18:49:53 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRWlGSWpSXmKPExsXiVRtkoBtQJBV u8O49o8XvvrWMDowehz9cYQlgjGLNzEvKr0hgzbh/+wx7wQGlit9rpzM3MF6R6WLk4hASmM4o cW3zRTYQh0VgFqtER+N6IIeTQ0JgG6vEiWtmEHaMxIY395i6GDmA7AqJ1ZcqQcJCAuoS9xbdZ ocY9IVR4vKLs0wgCWagxJ95l5hBbF4BPYlXty6zgtjCAkkSz67+YASx2QS0JTbdeMAMMpNTwF ZiypFKEJNFQFWicaEFyEhmgTWMEtcXH4EaqS2xbOFrsHJeARuJpg0cECfYSDxcuZEVpF5EYBa jREdTIwvEybISu38/YprAKDwLyUWzkFw0C8nYBYzMqxjVi1OLylKLdC31kooy0zNKchMzc3QN DUz1clOLixPTU3MSk4r1kvNzNzECg5wBCHYwrm11PsQoycGkJMrrFSIVLsSXlJ9SmZFYnBFfV JqTWnyIUYaDQ0mCd1UhUE6wKDU9tSItMwcYbzBpCQ4eJRHeBpA0b3FBYm5xZjpE6hSjLseWqf fWMgmx5OXnpUqJ8x4AKRIAKcoozYMbAYv9S4yyUsK8jEBHCfEUpBblZpagyr9iFOdgVBLm9Qa ZwpOZVwK36RXQEUxAR/y7IAlyREkiQkqqgZFZ5NYJy5y+jFMbgvWep6ovEbxy8W3QyaUZj3aq HJRb8EuB4+66dV8SDRpKDsZE24S9v/hzyszEAEO/tq+VsnkcMzOu9UxQFPR1cpDtODClrZn9W ++d7jqmT+mvdqUqiiT6bDn89m51sZORieHH6xNLRTfsXzTfuzpA8NCnRZKnP6o8L1jDoaPEUp yRaKjFXFScCADo4Uvc+AIAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1461350991!18808645!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 61764 invoked from network); 22 Apr 2016 18:49:52 -0000 Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by server-10.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 22 Apr 2016 18:49:52 -0000 Received: by mail-wm0-f48.google.com with SMTP id n3so40069807wmn.0 for ; Fri, 22 Apr 2016 11:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z6I8zd4GeccOYbyYUc6/NeHiRmN5S4Jx9LCLbOkXF5s=; b=wQzRyak42iso61zU4Z1Plxnowl+1SUbbmGaX6jcRfI/08Ccddws3WmJZj9pXYdNUNO HhsNNeO7cLsPlORfGfxDBBqwVYx+0ILdsENEEQ8P7K1IDeZrhskC5M+MlefOu0fOdm79 uqUFLSD+YY2g3wQYMW5jKC8pFvdnJeKHFdZ34b37gILEfY8VnXgvVpulIoH472mly6aC SUXjar25sj291Bmo/mz2OAhrRpUkezzMuL2hoiZgqSzxex2Q5KS0La20Z6OXNQHFbhzm sxqWhfvaipWhkvBLVTX+ouayYdLoLkRoqnxvykAP87eROtUxDgrajtUwJMOiWMD2RX9O wyHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z6I8zd4GeccOYbyYUc6/NeHiRmN5S4Jx9LCLbOkXF5s=; b=eKmgYzOL9z8d5hre4sMeSYmkqcJ9aA/i53nZIUcxg5naEmleV/VWlkE38CRpagAoHy rIgmBuOLYZXzsAvhf1jpBv4lmzwDGsdZs1euiO7eQGXyB6vHmcVLLdVTjSzRwGz1cZkp ftB7zfhHwps9HbxfZOXwSPAXlT12NvIb1xqbNBkegORmxeD8YKSpXwnlKKieLGkihd5N A+l03YJFTdoItuH2Ot1K66S8r5cPHIHDmb/OSo920ssU4eXS5exM/8xv1KM+E3OmWEGT J/JzPZe1MDBovp5jbJEQhvl4gvpbooraJ56es6AwoOKd7EDvyAhBkXwEjUMDEbipapex l0Ng== X-Gm-Message-State: AOPr4FXcSfpg23/V8VRPWEO+tkvLOSYkFarBtzeDdz/uFjpO4BCrWhvcxr8MuJrKUceDOw== X-Received: by 10.28.92.69 with SMTP id q66mr5655256wmb.102.1461350991717; Fri, 22 Apr 2016 11:49:51 -0700 (PDT) Received: from [192.168.0.12] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id u3sm4640249wmg.15.2016.04.22.11.49.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 11:49:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Fri, 22 Apr 2016 19:49:50 +0100 Message-Id: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> References: To: publicity@lists.xenproject.org, appointments@xenproject.org, Sarah Conway , Zibby Keaton X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , Andrew Cooper , George Dunlap , sstabellini@kernel.org Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" Cj4gT24gMjIgQXByIDIwMTYsIGF0IDE5OjQ4LCBMYXJzIEt1cnRoIDxsYXJzLmt1cnRoLnhlbkBn bWFpbC5jb20+IHdyb3RlOgo+IAo+IFNlZSBodHRwczovL2Jsb2cueGVucHJvamVjdC5vcmcvP3A9 MTEzMTAmcHJldmlldz10cnVlCj4gSSB3b3VsZCBsaWtlIHRvIHB1Ymxpc2ggb24gTW9uZGF5Cj4g Cj4gVGhvc2Ugb24gdGhlIENDIGxpc3Q6IEkgbWFkZSB1cCBzb21lIHNob3J0IGJpb3MgZm9yIGVh Y2ggb2YgeW91LCBiYXNlZCBvbiB3aGF0IEkga25vdy4gRmVlbCBmcmVlIHRvIHN1Z2dlc3QgY29y cmVjdGlvbnMvYWRkaXRpb25zLgo+IAo+IEBaaWJieTogY291bGQgeW91IGdvIHRocm91Z2ggdGhp cyB3aXRoIGEgdmlldyB0b3dhcmRzIG1lZGlhIGltcGFjdCAoZS5nLiBhIHBvc3NpYmx5IG5lZ2F0 aXZlIHJlZ2lzdGVyIHN0b3J5KS4gV2UgYXJlIGludGVudGlvbmFsbHkgbm90IHN0YXRpbmcgY29t cGFueSBhZmZpbGlhdGlvbi4KPiAKPiBMYXJzCgoKSSBhZGRlZCB0aGUgdGV4dCAodW5mb3JtYXR0 ZWQpIGZvciBjb252ZW5pZW5jZQpMYXJzCgotLS0KCkEgY291cGxlIG9mIG1vbnRocyBhZ28gdHdv IG9mIG91ciBjb21taXR0ZXJzLCBLZWlyIEZyYXNlciBhbmQgVGltIERlZWdhbiwgaGF2ZSBmb3Jt YWxseSBzdGVwcGVkIGRvd24gaW4gdGhlaXIgcm9sZXMgYXMgY29tbWl0dGVycyBmcm9tIHRoZSBI eXBlcnZpc29yIHRlYW0sIHdoaWxlIG90aGVycyBoYXZlIGNoYW5nZWQgdGhlaXIgZm9jdXMgb3Ig bGV2ZWwgb2YgaW52b2x2ZW1lbnQgaW4gdGhlIHByb2plY3QuClVuZm9ydHVuYXRlbHksIHRoZSBw cm9qZWN0IGhhcyBmb3VuZCBpdCBkaWZmaWN1bHQgdG8gcHJvbW90ZSBjb250cmlidXRvcnMgdG8g bWFpbnRhaW5lciBhbmRjb21taXR0ZXIgcm9sZXMsIHdoaWNoIGNvbnN0aXR1dGUgdGhlIGxlYWRl cnNoaXAgb2YgdGhlIFhlbiBQcm9qZWN0IEh5cGVydmlzb3IgVGVhbS4gVGhpcyB3YXMgdHJ1ZSwg ZGVzcGl0ZSBhbiBhY3RpdmVseSBncm93aW5nIGNvbW11bml0eSAoc2VlIGRpYWdyYW0gb24gdGhl IHJpZ2h0KS4KCkFmdGVyIHNvbWUgc291bCBzZWFyY2hpbmcsIHdlIHJlYWxpc2VkIHRoYXQgdGhl IHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGlzc3VlIHdhcyBub3QgdGhhdCB3ZSBkaWRu4oCZdCBo YXZlIGZ1dHVyZSBsZWFkZXJzIHdpdGhpbiB0aGUgY29tbXVuaXR5LiBUaGUgaXNzdWUgd2FzIHNp bXBseSB0aGF0IHdlIGRpZG7igJl0IGhhdmUgYW4gb3JnYW5pc2VkIGFwcHJvYWNoIHRvIHN1Y2Nl c3Npb24gcGxhbm5pbmc6IGFjdGl2ZSBkZXZlbG9wZXJzIHNpbXBseSB3b3JrZWQgb24gdGhlIHBy b2plY3QgYW5kIGRpZCBub3QgY29uc2lkZXIgdG8gbm9taW5hdGUgbmV3Y29tZXJzIChvciB0aGVt c2VsdmVzKSBmb3IgbGVhZGVyc2hpcCByb2xlcyB3aXRoaW4gdGhlIHByb2plY3QuIFRvIGZpeCB0 aGlzLCB3ZSBpbnRyb2R1Y2VkIGEgbmV3IGNvbnZlbnRpb24sIGJ5IHdoaWNoIHdlIGFjdGl2ZWx5 IHJlbWluZCBjb21tdW5pdHkgbWVtYmVycyB0byBub21pbmF0ZSBvciBzZWxmLW5vbWluYXRlIHRo ZW1zZWx2ZXMgZm9yIGxlYWRlcnNoaXAgcm9sZXMuCgpUaGlzIGFwcHJvYWNoIGhhcyB3b3JrZWQg dmVyeSB3ZWxsLCBhbmQgSSBhbSBwbGVhc2VkIHRvIGFubm91bmNlIHRoZSBmb2xsb3dpbmcgbmV3 IG1lbWJlcnMgdG8gdGhlIFhlbiBQcm9qZWN0IEh5cGVydmlzb3IgTGVhZGVyc2hpcCBUZWFtLiBI b3dldmVyLCBiZWZvcmUgZG9pbmcgc28sIEkgd2FudGVkIHRvIHRoYW5rIEtlaXIgYW5kIFRpbSBm b3IgdGhlaXIgdmFzdCBjb250cmlidXRpb25zIHRvIHRoZSBwcm9qZWN0LgoKQ29tbWl0dGVycwoK VGhlIGZvbGxvd2luZyBwZW9wbGUgaGF2ZSBiZWVuIGVsZWN0ZWQgdG8gYmUgbmV3IENvbW1pdHRl cnMgdG8gdGhlIHByb2plY3QsIGFsb25nc2lkZSBJYW4gQ2FtcGJlbGwsIElhbiBKYWNrc29uLCBK YW4gQmV1bGljaCBhbmQgS29ucmFkIFJ6ZXN6dXRlayBXaWxrOgoKQW5kcmV3IENvb3BlciBoYXMg YmVlbiB3b3JraW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMTEgYW5kIGhhcyBhZGRlZCBh IG51bWJlciBvZiBtYWpvciBuZXcgZmVhdHVyZXMgc3VjaCBhcyBNaWdyYXRpb24gdjIsIHNpZ25p ZmljYW50IGNoYW5nZSB0byB0cmFwIGhhbmRsaW5nLCBpbXByb3ZlbWVudHMgdG8gY3B1aWQgaGFu ZGxpbmcgZm9yIGd1ZXN0cyBhbmQgbWFueSBtb3JlLgoKR2VvcmdlIER1bmxhcCBoYXMgYmVlbiB3 b3JraW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMDggYW5kIHdhcyBoZWF2aWx5IGludm9s dmVkIGluIG1ha2luZyB0aGUgdHJhY2luZyBzeXN0ZW0gdXNlYWJsZSBmb3IKcGVyZm9ybWFuY2Ug YW5hbHlzaXMsIG9wdGltaXNpbmcgdGhlIHNoYWRvdyBjb2RlLCB3cm90ZSB0aGUgY3JlZGl0MiBz Y2hlZHVsZXIgYW5kIGRldmVsb3BlZCBtYW55IG90aGVyIHNpZ25pZmljYW50IGZlYXR1cmVzIGFu ZCBpbXByb3ZlbWVudHMgaW4gdGhlIGh5cGVydmlzb3IuIEluIGFkZGl0aW9uLCBoZSB3YXMgb3Vy IGZpcnN0IFJlbGVhc2UgTWFuYWdlciBhbmQgaXMgbGVhZGluZyB0aGUgQ2VudE9TIFZpcnR1YWxp c2F0aW9uIFNJRyB3aXRoaW4gQ2VudE9TLgoKU3RlZmFubyBTdGFiZWxsaW5pIGhhcyBiZWVuIHdv cmtpbmcgb24gdGhlIEh5cGVydmlzb3IgYW5kIHRoZSBMaW51eCBLZXJuZWwgc2luY2UgMjAwOCBh bmQgd2FzIGluc3RydW1lbnRhbCBpbiBicmluZ2luZyBBUk0gc3VwcG9ydCB0byB0aGUgWGVuIEh5 cGVydmlzb3IuIEhlIGhhcyBhbHNvIGJlZW4gbGVhZGluZyBtYW55IG90aGVyIGFjdGl2aXRpZXMg d2l0aGluIHRoZSBwcm9qZWN0LCBzdWNoIGFzIE9wZW5TdGFjayBpbnRlZ3JhdGlvbiBhbmQgUmFp c2luLgoKV2VpIExpdSBzdGFydGVkIHRvIHdvcmsgb24gdGhlIFhlbiBQcm9qZWN0IGFzIGEgR1Nv QyBzdHVkZW50IGluIDIwMTEgKHdvcmtpbmcgaW4gdmlydGlvIHN1cHBvcnQpLiBIZSBoYXMgYmVl biB3b3JraW5nIG9uIGxpYnhsIHN1cHBvcnQsIGV2ZW50IGNoYW5uZWwgc2NhbGFiaWxpdHksIE1p bmlPUyBhbmQgbWFueSBvdGhlciBtYWpvciBYZW4gZmVhdHVyZXMuIEluIGFkZGl0aW9uIGhlIGhh cyBiZWVuIHRoZSBYZW4gUHJvamVjdCBSZWxlYXNlIE1hbmFnZXIgc2luY2UgWGVuIFByb2plY3Qg NC42IHJlbGVhc2UuCgpBbmRyZXcgYW5kIFdlaSBjZWxlYnJhdGVkIHRoZWlyIGFwcG9pbnRtZW50 IGF0IG9uZSBvZiB0aGUgWGVuIFByb2plY3Qgc29jaWFsIGV2ZW50cyBlYXJsaWVyIHRoaXMgd2Vl aywgYnkgc3VibWl0dGluZyBhbmQgQUNLaW5nIGEgcGllY2Ugb2YgY29kZSB3aGlsZSBvbiBhIHB1 bnQgb24gdGhlIHJpdmVyIENhbSBpbiBDYW1icmlkZ2UsIFVLLgoKClNlY3VyaXR5IFRlYW0KCklu IGFkZGl0aW9uLCBBbmRyZXcgQ29vcGVyIGFuZCBHZW9yZ2UgRHVubGFwIGFyZSBub3cgYWxzbyBt ZW1iZXJzIG9mIHRoZSBYZW4gUHJvamVjdCBTZWN1cml0eSBUZWFtLCBhbG9uZ3NpZGUgSWFuIEph Y2tzb24sIEphbiBCZXVsaWNoIGFuZCBUaW0gRGVlZ2FuLgoKTWFpbnRhaW5lcnMKClRoZSBmb2xs b3dpbmcgcGVvcGxlIHdlcmUgYWxzbyByZWNlbnRseSBhZGRlZCBhcyBNQUlOVEFJTkVSUyBvZiB0 aGUgcHJvamVjdDogRG91ZyBHb2xkc3RlaW4oS0NvbmZpZywgVHJhdmlzIENJKSwgSnVsaWVuIEdy YWxsIChBUk0gc3VwcG9ydCwgZGV2aWNlIHRyZWUsIOKApiksIE1lbmcgWHUgKFJURFMgU2NoZWR1 bGVyKSBhbmRQYXVsIER1cnJhbnQgKHg4NiBJL08gZW11bGF0aW9uLCB4ODYgdmlyaWRpYW4gZW5s aWdodGVubWVudHMsIOKApikuIEluIGFkZGl0aW9uLCB3ZSBjbGFyaWZpZWQgc29tZSBhbWJpZ3Vp dGllcyBhcm91bmQgdGhlIG1haW50YWluZXIgcm9sZS4KCkxpbnV4IEtlcm5lbCBNYWludGFpbmVy cwoKSsO8cmdlbiBHcm9zcyB3aG8gaGFzIGJlZW4gYSBMaW51eCBrZXJuZWwgYW5kIFhlbiBkZXZl bG9wZXIgc2luY2UgMjAwNCwgYnV0IGhhcyBzaWduaWZpY2FudGx5IGluY3JlYXNlZCBoaXMgZW5n YWdlbWVudCB3aXRoaW4gdGhlIGNvbW11bml0eSBpbiB0aGUgbGFzdCB0d28geWVhcnMsIGFuZCBp cyBub3cgTGludXggS2VybmVsIG1haW50YWluZXIgZm9yIHRoZSBYZW4gSHlwZXJ2aXNvciBJbnRl cmZhY2UgYWxvbmdzaWRlIEJvcmlzIE9zdHJvdnNreSBhbmQgRGF2aWQgVnJhYmVsLiBPdGhlciBt YWludGFpbmVycyBvZiBYZW4gc3BlY2lmaWMgY29tcG9uZW50cyBpbiB0aGUgTGludXggS2VybmVs IGFyZTogU3RlZmFubyBTdGFiZWxsaW5pLCBXZWkgTHVpLCBhbmQgS29ucmFkIFJ6ZXN6dXRlayBX aWxrLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpQdWJs aWNpdHkgbWFpbGluZyBsaXN0ClB1YmxpY2l0eUBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwOi8v bGlzdHMueGVucHJvamVjdC5vcmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL3B1YmxpY2l0eQo= From publicity-bounces@lists.xenproject.org Fri Apr 22 21:11:34 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 Apr 2016 21:11:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atiMQ-0003Pc-12; Fri, 22 Apr 2016 21:11:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ath4E-0004MF-7N for publicity@lists.xenproject.org; Fri, 22 Apr 2016 19:48:42 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 50/C8-07924-9108A175; Fri, 22 Apr 2016 19:48:41 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRWlGSWpSXmKPExsVyMfT+Wl2JBql wg+e/uCx+961ldGD0OPzhCksAYxRrZl5SfkUCa8b8ExtYCmYmVpxq2sDYwLg4qIuRi0NIYDaj xNYXR9lBHBaBfcwS3x/cZgRxJATmsEpc33EAyOEAcnIk5t8L7GLk5OAVEJQ4OfMJC4gtIVAgc XnhLiYQW0jAU+L/pHmsIDangK3E1l13WSDieRIvJ64Fi7MIqErcm7OJFWJOgETzyoPMILawQL LEnLsPGUFsNgEDiYnnb4DZIgKaEhOv7WcFuYdZYDqTRP/Vg+wgCWYBL4llx5sZJzAKzEJy0yw kqVlAZzMLqEusnycEEdaWWLbwNTOErSZxe9tVdmTxBYxsqxjVi1OLylKLdI31kooy0zNKchMz c3QNDYz1clOLixPTU3MSk4r1kvNzNzECw5wBCHYwNn9xOsQoycGkJMrrFSIVLsSXlJ9SmZFYn BFfVJqTWnyIUYaDQ0mCl78eKCdYlJqeWpGWmQOMOJi0BAePkghvMkiat7ggMbc4Mx0idYrRmG PL72trmTi2Tb23lkmIJS8/L1VKnFccpFQApDSjNA9uECwRXGKUlRLmZQQ6TYinILUoN7MEVf4 VozgHo5IwrzLIFJ7MvBK4fa+ATmECOuXfBUmQU0oSEVJSDYy5Kzf9nLPs7IUZdbZ70vd+EpL4 Pe/WkvXS864eiP1jmdK9cHL2JgH7ya+m9B3i2PircP+j9jPrC/KCP6345FCTPOnMcfkDTVEvf m0V8XHqFD3vqyzWGGw2P2nWRgeV+wb7pywx5hdsta9NbPpct4qDMWuyd34tx+4jQspH7iS9LA 6Te/2oR/yeEktxRqKhFnNRcSIA8aGgxv8CAAA= X-Env-Sender: zkeaton@linuxfoundation.org X-Msg-Ref: server-2.tower-31.messagelabs.com!1461354519!36471860!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32221 invoked from network); 22 Apr 2016 19:48:39 -0000 Received: from mail-io0-f173.google.com (HELO mail-io0-f173.google.com) (209.85.223.173) by server-2.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 22 Apr 2016 19:48:39 -0000 Received: by mail-io0-f173.google.com with SMTP id u185so129611553iod.3 for ; Fri, 22 Apr 2016 12:48:39 -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; bh=nm1IJgs13stwTWdfmEsleD99VbPThssEJBmzgIoYkC8=; b=aEWhTQ60Dmq1+m9wqgmJVibMqOvXwMRAScD5tTYMsL+ZMITVC1zxaijV6GMJOPBGyo lnZKE99/vDUG72ykjmpAb51d1WELcku900siHZ/AGRlARmodbnSZYE2CannAHs16UBV3 UHFIHHF8nywMsjLDFLy4xupvjYnjN2svTqvOI= 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; bh=nm1IJgs13stwTWdfmEsleD99VbPThssEJBmzgIoYkC8=; b=YW5P5dDxA/6FRNgALp1XIEQ2vYSTXz2qEiVw4QvEmBlx7xp0cMPsMJ6vrmXwrZUWuU t+DD+9PV9DykJzY7dDm9tZ9SZcN1oUcCbIFEAnll9GJYXSe7qR6m+KsUMevuc6EUBdht cXAteI9ZSN3VXvko4+/ag101144p1UoS0m/S4L5POHzX5MBDfRglw6E8co6OIDmyPUyX IPlGVk2J6dy2Er4RAN/NR1B0h0eIBmjwB+Ai1opwyBIYSIYWtQkZb0ppfiLZ5p74jEtl SAMZ3aWbiiuGu5UYEC+F/4vciF2EdTdUXm2P++r1NIYBcdVakro4aYsl8T+20JrbKw9/ aJAg== X-Gm-Message-State: AOPr4FVClMo1httMsQpxP4TCjqh3rac+filBWCJczoVVZgnLso3l/yPeXJ0Z9XeFamNV9gp2wjNaKgr5oJQkmv7h MIME-Version: 1.0 X-Received: by 10.107.50.4 with SMTP id y4mr25487846ioy.10.1461354518742; Fri, 22 Apr 2016 12:48:38 -0700 (PDT) Received: by 10.36.51.81 with HTTP; Fri, 22 Apr 2016 12:48:38 -0700 (PDT) In-Reply-To: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> Date: Fri, 22 Apr 2016 15:48:38 -0400 Message-ID: From: Zibby Keaton To: Lars Kurth X-Mailman-Approved-At: Fri, 22 Apr 2016 21:11:32 +0000 Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , George Dunlap , appointments@xenproject.org, publicity@lists.xenproject.org Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============4316774694443852658==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============4316774694443852658== Content-Type: multipart/alternative; boundary=001a11447a7efb31140531181ca0 --001a11447a7efb31140531181ca0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all - I just spoke with Lars about this via Skype and I think there's potential for this to be a story that we present to the media. It shows that you are growing and evolving as a community. Next week is the OpenStack Summit and most of our reporters will be covering the news coming out of the conference. So we don't get drowned out in noise, I suggest we publish this week of May 2nd. Sarah and I will work on media strategy here and update the copy appropriately. I want to make sure that everyone is in the loop and knows what's happening next. Let me know if you have any questions or concerns. Zibby On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth wrote: > > > On 22 Apr 2016, at 19:48, Lars Kurth wrote: > > > > See https://blog.xenproject.org/?p=3D11310&preview=3Dtrue > > I would like to publish on Monday > > > > Those on the CC list: I made up some short bios for each of you, based > on what I know. Feel free to suggest corrections/additions. > > > > @Zibby: could you go through this with a view towards media impact (e.g= . > a possibly negative register story). We are intentionally not stating > company affiliation. > > > > Lars > > > I added the text (unformatted) for convenience > Lars > > --- > > A couple of months ago two of our committers, Keir Fraser and Tim Deegan, > have formally stepped down in their roles as committers from the Hypervis= or > team, while others have changed their focus or level of involvement in th= e > project. > Unfortunately, the project has found it difficult to promote contributors > to maintainer andcommitter roles, which constitute the leadership of the > Xen Project Hypervisor Team. This was true, despite an actively growing > community (see diagram on the right). > > After some soul searching, we realised that the primary reason for this > issue was not that we didn=E2=80=99t have future leaders within the commu= nity. The > issue was simply that we didn=E2=80=99t have an organised approach to suc= cession > planning: active developers simply worked on the project and did not > consider to nominate newcomers (or themselves) for leadership roles withi= n > the project. To fix this, we introduced a new convention, by which we > actively remind community members to nominate or self-nominate themselves > for leadership roles. > > This approach has worked very well, and I am pleased to announce the > following new members to the Xen Project Hypervisor Leadership Team. > However, before doing so, I wanted to thank Keir and Tim for their vast > contributions to the project. > > Committers > > The following people have been elected to be new Committers to the > project, alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad > Rzeszutek Wilk: > > Andrew Cooper has been working on the Hypervisor since 2011 and has added > a number of major new features such as Migration v2, significant change t= o > trap handling, improvements to cpuid handling for guests and many more. > > George Dunlap has been working on the Hypervisor since 2008 and was > heavily involved in making the tracing system useable for > performance analysis, optimising the shadow code, wrote the credit2 > scheduler and developed many other significant features and improvements = in > the hypervisor. In addition, he was our first Release Manager and is > leading the CentOS Virtualisation SIG within CentOS. > > Stefano Stabellini has been working on the Hypervisor and the Linux Kerne= l > since 2008 and was instrumental in bringing ARM support to the Xen > Hypervisor. He has also been leading many other activities within the > project, such as OpenStack integration and Raisin. > > Wei Liu started to work on the Xen Project as a GSoC student in 2011 > (working in virtio support). He has been working on libxl support, event > channel scalability, MiniOS and many other major Xen features. In additio= n > he has been the Xen Project Release Manager since Xen Project 4.6 release= . > > Andrew and Wei celebrated their appointment at one of the Xen Project > social events earlier this week, by submitting and ACKing a piece of code > while on a punt on the river Cam in Cambridge, UK. > > > Security Team > > In addition, Andrew Cooper and George Dunlap are now also members of the > Xen Project Security Team, alongside Ian Jackson, Jan Beulich and Tim > Deegan. > > Maintainers > > The following people were also recently added as MAINTAINERS of the > project: Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, > device tree, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 I/= O > emulation, x86 viridian enlightenments, =E2=80=A6). In addition, we clari= fied some > ambiguities around the maintainer role. > > Linux Kernel Maintainers > > J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since 200= 4, but > has significantly increased his engagement within the community in the la= st > two years, and is now Linux Kernel maintainer for the Xen Hypervisor > Interface alongside Boris Ostrovsky and David Vrabel. Other maintainers o= f > Xen specific components in the Linux Kernel are: Stefano Stabellini, Wei > Lui, and Konrad Rzeszutek Wilk. --=20 Zibby Keaton The Linux Foundation PR Manager *208-290-4853zkeaton@linuxfoundation.org * Skype: zibby.keaton Twitter: ZibbyK --001a11447a7efb31140531181ca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all -

I just spoke with Lars about t= his via Skype and I think there's potential for this to be a story that= we present to the media. It shows that you are growing and evolving as a c= ommunity. Next week is the OpenStack Summit and most of our reporters will = be covering the news coming out of the conference.

So we don't get drowned out in noise, I suggest we publish this week o= f May 2nd. Sarah and I will work on media strategy here and update the copy= appropriately.

I want to make sure that every= one is in the loop and knows what's happening next.=C2=A0
Let me know if you have any questions or concerns.
Zibby

On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth = <lars.kurt= h.xen@gmail.com> wrote:

> On 22 Apr 2016, at 19:48, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
>
> See https://blog.xenproject.org/?p=3D1= 1310&preview=3Dtrue
> I would like to publish on Monday
>
> Those on the CC list: I made up some short bios for each of you, based= on what I know. Feel free to suggest corrections/additions.
>
> @Zibby: could you go through this with a view towards media impact (e.= g. a possibly negative register story). We are intentionally not stating co= mpany affiliation.
>
> Lars


I added the text (unformatted) for convenience
Lars

---

A couple of months ago two of our committers, Keir Fraser and Tim Deegan, h= ave formally stepped down in their roles as committers from the Hypervisor = team, while others have changed their focus or level of involvement in the = project.
Unfortunately, the project has found it difficult to promote contributors t= o maintainer andcommitter roles, which constitute the leadership of the Xen= Project Hypervisor Team. This was true, despite an actively growing commun= ity (see diagram on the right).

After some soul searching, we realised that the primary reason for this iss= ue was not that we didn=E2=80=99t have future leaders within the community.= The issue was simply that we didn=E2=80=99t have an organised approach to = succession planning: active developers simply worked on the project and did= not consider to nominate newcomers (or themselves) for leadership roles wi= thin the project. To fix this, we introduced a new convention, by which we = actively remind community members to nominate or self-nominate themselves f= or leadership roles.

This approach has worked very well, and I am pleased to announce the follow= ing new members to the Xen Project Hypervisor Leadership Team. However, bef= ore doing so, I wanted to thank Keir and Tim for their vast contributions t= o the project.

Committers

The following people have been elected to be new Committers to the project,= alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad Rzeszutek Wilk= :

Andrew Cooper has been working on the Hypervisor since 2011 and has added a= number of major new features such as Migration v2, significant change to t= rap handling, improvements to cpuid handling for guests and many more.

George Dunlap has been working on the Hypervisor since 2008 and was heavily= involved in making the tracing system useable for
performance analysis, optimising the shadow code, wrote the credit2 schedul= er and developed many other significant features and improvements in the hy= pervisor. In addition, he was our first Release Manager and is leading the = CentOS Virtualisation SIG within CentOS.

Stefano Stabellini has been working on the Hypervisor and the Linux Kernel = since 2008 and was instrumental in bringing ARM support to the Xen Hypervis= or. He has also been leading many other activities within the project, such= as OpenStack integration and Raisin.

Wei Liu started to work on the Xen Project as a GSoC student in 2011 (worki= ng in virtio support). He has been working on libxl support, event channel = scalability, MiniOS and many other major Xen features. In addition he has b= een the Xen Project Release Manager since Xen Project 4.6 release.

Andrew and Wei celebrated their appointment at one of the Xen Project socia= l events earlier this week, by submitting and ACKing a piece of code while = on a punt on the river Cam in Cambridge, UK.


Security Team

In addition, Andrew Cooper and George Dunlap are now also members of the Xe= n Project Security Team, alongside Ian Jackson, Jan Beulich and Tim Deegan.=

Maintainers

The following people were also recently added as MAINTAINERS of the project= : Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, device tre= e, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 I/O emulation,= x86 viridian enlightenments, =E2=80=A6). In addition, we clarified some am= biguities around the maintainer role.

Linux Kernel Maintainers

J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since 2004,= but has significantly increased his engagement within the community in the= last two years, and is now Linux Kernel maintainer for the Xen Hypervisor = Interface alongside Boris Ostrovsky and David Vrabel. Other maintainers of = Xen specific components in the Linux Kernel are: Stefano Stabellini, Wei Lu= i, and Konrad Rzeszutek Wilk.


=
--
Zibby Keaton
= The Linux Foundation
PR Manag= er
20= 8-290-4853
zkeaton@linuxfoundation.org
Skype: zibby.keatonT= witter: ZibbyK
--001a11447a7efb31140531181ca0-- --===============4316774694443852658== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============4316774694443852658==-- From publicity-bounces@lists.xenproject.org Fri Apr 22 21:11:34 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 Apr 2016 21:11:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atiMQ-0003Pc-12; Fri, 22 Apr 2016 21:11:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ath4E-0004MF-7N for publicity@lists.xenproject.org; Fri, 22 Apr 2016 19:48:42 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 50/C8-07924-9108A175; Fri, 22 Apr 2016 19:48:41 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRWlGSWpSXmKPExsVyMfT+Wl2JBql wg+e/uCx+961ldGD0OPzhCksAYxRrZl5SfkUCa8b8ExtYCmYmVpxq2sDYwLg4qIuRi0NIYDaj xNYXR9lBHBaBfcwS3x/cZgRxJATmsEpc33EAyOEAcnIk5t8L7GLk5OAVEJQ4OfMJC4gtIVAgc XnhLiYQW0jAU+L/pHmsIDangK3E1l13WSDieRIvJ64Fi7MIqErcm7OJFWJOgETzyoPMILawQL LEnLsPGUFsNgEDiYnnb4DZIgKaEhOv7WcFuYdZYDqTRP/Vg+wgCWYBL4llx5sZJzAKzEJy0yw kqVlAZzMLqEusnycEEdaWWLbwNTOErSZxe9tVdmTxBYxsqxjVi1OLylKLdI31kooy0zNKchMz c3QNDYz1clOLixPTU3MSk4r1kvNzNzECw5wBCHYwNn9xOsQoycGkJMrrFSIVLsSXlJ9SmZFYn BFfVJqTWnyIUYaDQ0mCl78eKCdYlJqeWpGWmQOMOJi0BAePkghvMkiat7ggMbc4Mx0idYrRmG PL72trmTi2Tb23lkmIJS8/L1VKnFccpFQApDSjNA9uECwRXGKUlRLmZQQ6TYinILUoN7MEVf4 VozgHo5IwrzLIFJ7MvBK4fa+ATmECOuXfBUmQU0oSEVJSDYy5Kzf9nLPs7IUZdbZ70vd+EpL4 Pe/WkvXS864eiP1jmdK9cHL2JgH7ya+m9B3i2PircP+j9jPrC/KCP6345FCTPOnMcfkDTVEvf m0V8XHqFD3vqyzWGGw2P2nWRgeV+wb7pywx5hdsta9NbPpct4qDMWuyd34tx+4jQspH7iS9LA 6Te/2oR/yeEktxRqKhFnNRcSIA8aGgxv8CAAA= X-Env-Sender: zkeaton@linuxfoundation.org X-Msg-Ref: server-2.tower-31.messagelabs.com!1461354519!36471860!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32221 invoked from network); 22 Apr 2016 19:48:39 -0000 Received: from mail-io0-f173.google.com (HELO mail-io0-f173.google.com) (209.85.223.173) by server-2.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 22 Apr 2016 19:48:39 -0000 Received: by mail-io0-f173.google.com with SMTP id u185so129611553iod.3 for ; Fri, 22 Apr 2016 12:48:39 -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; bh=nm1IJgs13stwTWdfmEsleD99VbPThssEJBmzgIoYkC8=; b=aEWhTQ60Dmq1+m9wqgmJVibMqOvXwMRAScD5tTYMsL+ZMITVC1zxaijV6GMJOPBGyo lnZKE99/vDUG72ykjmpAb51d1WELcku900siHZ/AGRlARmodbnSZYE2CannAHs16UBV3 UHFIHHF8nywMsjLDFLy4xupvjYnjN2svTqvOI= 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; bh=nm1IJgs13stwTWdfmEsleD99VbPThssEJBmzgIoYkC8=; b=YW5P5dDxA/6FRNgALp1XIEQ2vYSTXz2qEiVw4QvEmBlx7xp0cMPsMJ6vrmXwrZUWuU t+DD+9PV9DykJzY7dDm9tZ9SZcN1oUcCbIFEAnll9GJYXSe7qR6m+KsUMevuc6EUBdht cXAteI9ZSN3VXvko4+/ag101144p1UoS0m/S4L5POHzX5MBDfRglw6E8co6OIDmyPUyX IPlGVk2J6dy2Er4RAN/NR1B0h0eIBmjwB+Ai1opwyBIYSIYWtQkZb0ppfiLZ5p74jEtl SAMZ3aWbiiuGu5UYEC+F/4vciF2EdTdUXm2P++r1NIYBcdVakro4aYsl8T+20JrbKw9/ aJAg== X-Gm-Message-State: AOPr4FVClMo1httMsQpxP4TCjqh3rac+filBWCJczoVVZgnLso3l/yPeXJ0Z9XeFamNV9gp2wjNaKgr5oJQkmv7h MIME-Version: 1.0 X-Received: by 10.107.50.4 with SMTP id y4mr25487846ioy.10.1461354518742; Fri, 22 Apr 2016 12:48:38 -0700 (PDT) Received: by 10.36.51.81 with HTTP; Fri, 22 Apr 2016 12:48:38 -0700 (PDT) In-Reply-To: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> Date: Fri, 22 Apr 2016 15:48:38 -0400 Message-ID: From: Zibby Keaton To: Lars Kurth X-Mailman-Approved-At: Fri, 22 Apr 2016 21:11:32 +0000 Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , George Dunlap , appointments@xenproject.org, publicity@lists.xenproject.org Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============4316774694443852658==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============4316774694443852658== Content-Type: multipart/alternative; boundary=001a11447a7efb31140531181ca0 --001a11447a7efb31140531181ca0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all - I just spoke with Lars about this via Skype and I think there's potential for this to be a story that we present to the media. It shows that you are growing and evolving as a community. Next week is the OpenStack Summit and most of our reporters will be covering the news coming out of the conference. So we don't get drowned out in noise, I suggest we publish this week of May 2nd. Sarah and I will work on media strategy here and update the copy appropriately. I want to make sure that everyone is in the loop and knows what's happening next. Let me know if you have any questions or concerns. Zibby On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth wrote: > > > On 22 Apr 2016, at 19:48, Lars Kurth wrote: > > > > See https://blog.xenproject.org/?p=3D11310&preview=3Dtrue > > I would like to publish on Monday > > > > Those on the CC list: I made up some short bios for each of you, based > on what I know. Feel free to suggest corrections/additions. > > > > @Zibby: could you go through this with a view towards media impact (e.g= . > a possibly negative register story). We are intentionally not stating > company affiliation. > > > > Lars > > > I added the text (unformatted) for convenience > Lars > > --- > > A couple of months ago two of our committers, Keir Fraser and Tim Deegan, > have formally stepped down in their roles as committers from the Hypervis= or > team, while others have changed their focus or level of involvement in th= e > project. > Unfortunately, the project has found it difficult to promote contributors > to maintainer andcommitter roles, which constitute the leadership of the > Xen Project Hypervisor Team. This was true, despite an actively growing > community (see diagram on the right). > > After some soul searching, we realised that the primary reason for this > issue was not that we didn=E2=80=99t have future leaders within the commu= nity. The > issue was simply that we didn=E2=80=99t have an organised approach to suc= cession > planning: active developers simply worked on the project and did not > consider to nominate newcomers (or themselves) for leadership roles withi= n > the project. To fix this, we introduced a new convention, by which we > actively remind community members to nominate or self-nominate themselves > for leadership roles. > > This approach has worked very well, and I am pleased to announce the > following new members to the Xen Project Hypervisor Leadership Team. > However, before doing so, I wanted to thank Keir and Tim for their vast > contributions to the project. > > Committers > > The following people have been elected to be new Committers to the > project, alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad > Rzeszutek Wilk: > > Andrew Cooper has been working on the Hypervisor since 2011 and has added > a number of major new features such as Migration v2, significant change t= o > trap handling, improvements to cpuid handling for guests and many more. > > George Dunlap has been working on the Hypervisor since 2008 and was > heavily involved in making the tracing system useable for > performance analysis, optimising the shadow code, wrote the credit2 > scheduler and developed many other significant features and improvements = in > the hypervisor. In addition, he was our first Release Manager and is > leading the CentOS Virtualisation SIG within CentOS. > > Stefano Stabellini has been working on the Hypervisor and the Linux Kerne= l > since 2008 and was instrumental in bringing ARM support to the Xen > Hypervisor. He has also been leading many other activities within the > project, such as OpenStack integration and Raisin. > > Wei Liu started to work on the Xen Project as a GSoC student in 2011 > (working in virtio support). He has been working on libxl support, event > channel scalability, MiniOS and many other major Xen features. In additio= n > he has been the Xen Project Release Manager since Xen Project 4.6 release= . > > Andrew and Wei celebrated their appointment at one of the Xen Project > social events earlier this week, by submitting and ACKing a piece of code > while on a punt on the river Cam in Cambridge, UK. > > > Security Team > > In addition, Andrew Cooper and George Dunlap are now also members of the > Xen Project Security Team, alongside Ian Jackson, Jan Beulich and Tim > Deegan. > > Maintainers > > The following people were also recently added as MAINTAINERS of the > project: Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, > device tree, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 I/= O > emulation, x86 viridian enlightenments, =E2=80=A6). In addition, we clari= fied some > ambiguities around the maintainer role. > > Linux Kernel Maintainers > > J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since 200= 4, but > has significantly increased his engagement within the community in the la= st > two years, and is now Linux Kernel maintainer for the Xen Hypervisor > Interface alongside Boris Ostrovsky and David Vrabel. Other maintainers o= f > Xen specific components in the Linux Kernel are: Stefano Stabellini, Wei > Lui, and Konrad Rzeszutek Wilk. --=20 Zibby Keaton The Linux Foundation PR Manager *208-290-4853zkeaton@linuxfoundation.org * Skype: zibby.keaton Twitter: ZibbyK --001a11447a7efb31140531181ca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all -

I just spoke with Lars about t= his via Skype and I think there's potential for this to be a story that= we present to the media. It shows that you are growing and evolving as a c= ommunity. Next week is the OpenStack Summit and most of our reporters will = be covering the news coming out of the conference.

So we don't get drowned out in noise, I suggest we publish this week o= f May 2nd. Sarah and I will work on media strategy here and update the copy= appropriately.

I want to make sure that every= one is in the loop and knows what's happening next.=C2=A0
Let me know if you have any questions or concerns.
Zibby

On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth = <lars.kurt= h.xen@gmail.com> wrote:

> On 22 Apr 2016, at 19:48, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
>
> See https://blog.xenproject.org/?p=3D1= 1310&preview=3Dtrue
> I would like to publish on Monday
>
> Those on the CC list: I made up some short bios for each of you, based= on what I know. Feel free to suggest corrections/additions.
>
> @Zibby: could you go through this with a view towards media impact (e.= g. a possibly negative register story). We are intentionally not stating co= mpany affiliation.
>
> Lars


I added the text (unformatted) for convenience
Lars

---

A couple of months ago two of our committers, Keir Fraser and Tim Deegan, h= ave formally stepped down in their roles as committers from the Hypervisor = team, while others have changed their focus or level of involvement in the = project.
Unfortunately, the project has found it difficult to promote contributors t= o maintainer andcommitter roles, which constitute the leadership of the Xen= Project Hypervisor Team. This was true, despite an actively growing commun= ity (see diagram on the right).

After some soul searching, we realised that the primary reason for this iss= ue was not that we didn=E2=80=99t have future leaders within the community.= The issue was simply that we didn=E2=80=99t have an organised approach to = succession planning: active developers simply worked on the project and did= not consider to nominate newcomers (or themselves) for leadership roles wi= thin the project. To fix this, we introduced a new convention, by which we = actively remind community members to nominate or self-nominate themselves f= or leadership roles.

This approach has worked very well, and I am pleased to announce the follow= ing new members to the Xen Project Hypervisor Leadership Team. However, bef= ore doing so, I wanted to thank Keir and Tim for their vast contributions t= o the project.

Committers

The following people have been elected to be new Committers to the project,= alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad Rzeszutek Wilk= :

Andrew Cooper has been working on the Hypervisor since 2011 and has added a= number of major new features such as Migration v2, significant change to t= rap handling, improvements to cpuid handling for guests and many more.

George Dunlap has been working on the Hypervisor since 2008 and was heavily= involved in making the tracing system useable for
performance analysis, optimising the shadow code, wrote the credit2 schedul= er and developed many other significant features and improvements in the hy= pervisor. In addition, he was our first Release Manager and is leading the = CentOS Virtualisation SIG within CentOS.

Stefano Stabellini has been working on the Hypervisor and the Linux Kernel = since 2008 and was instrumental in bringing ARM support to the Xen Hypervis= or. He has also been leading many other activities within the project, such= as OpenStack integration and Raisin.

Wei Liu started to work on the Xen Project as a GSoC student in 2011 (worki= ng in virtio support). He has been working on libxl support, event channel = scalability, MiniOS and many other major Xen features. In addition he has b= een the Xen Project Release Manager since Xen Project 4.6 release.

Andrew and Wei celebrated their appointment at one of the Xen Project socia= l events earlier this week, by submitting and ACKing a piece of code while = on a punt on the river Cam in Cambridge, UK.


Security Team

In addition, Andrew Cooper and George Dunlap are now also members of the Xe= n Project Security Team, alongside Ian Jackson, Jan Beulich and Tim Deegan.=

Maintainers

The following people were also recently added as MAINTAINERS of the project= : Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, device tre= e, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 I/O emulation,= x86 viridian enlightenments, =E2=80=A6). In addition, we clarified some am= biguities around the maintainer role.

Linux Kernel Maintainers

J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since 2004,= but has significantly increased his engagement within the community in the= last two years, and is now Linux Kernel maintainer for the Xen Hypervisor = Interface alongside Boris Ostrovsky and David Vrabel. Other maintainers of = Xen specific components in the Linux Kernel are: Stefano Stabellini, Wei Lu= i, and Konrad Rzeszutek Wilk.


=
--
Zibby Keaton
= The Linux Foundation
PR Manag= er
20= 8-290-4853
zkeaton@linuxfoundation.org
Skype: zibby.keatonT= witter: ZibbyK
--001a11447a7efb31140531181ca0-- --===============4316774694443852658== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============4316774694443852658==-- From publicity-bounces@lists.xenproject.org Mon Apr 25 08:31:50 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 Apr 2016 08:31:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aubvp-0003Fp-1t; Mon, 25 Apr 2016 08:31:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aubvn-0003Fj-Up for publicity@lists.xenproject.org; Mon, 25 Apr 2016 08:31:48 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id FD/FB-02914-3F5DD175; Mon, 25 Apr 2016 08:31:47 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleJIrShJLcpLzFFi42Lxqg0y1P14VTb cYPEnNYvffWsZHRg9Dn+4whLAGMWamZeUX5HAmnH18k3Ggs6qiuddt1kaGHdmdDFycQgJzGKU WHb3HguIwyLQwCpxYddnNhBHQmAOq8SmR6uAMpxAToxE7+0f7BB2lcTDzxuZQWwhAXWJe4tus 0OM+sIocWP6FFaQBLNAgsSpq7/AmnkF9CRe3boMFhcWSJJ4dvUHI4jNJqAtsenGA6BBHBycAo ES81fZgIRZBFQljkyaywQyk1lgPpNE5/olzBBzbCQWPlnKBrFsE6PEhP1r2EASIkALDrScZ4a 4TlZi9+9HTBMYhWYhuWMWkjsg4toSyxa+Zp4FtJtZQENi6+VkVGEQW13i6tqrrAsY2VYxqhen FpWlFuma6yUVZaZnlOQmZuboGhqa6OWmFhcnpqfmJCYV6yXn525iBMYGAxDsYPyyxPkQoyQHk 5Io78lDsuFCfEn5KZUZicUZ8UWlOanFhxhlODiUJHgZgbEmJFiUmp5akZaZA4xSmLQEB4+SCO +cS0Bp3uKCxNzizHSI1ClGXY4tU++tZRJiycvPS5US5xUAmSEAUpRRmgc3ApYwLjHKSgnzMgI dJcRTkFqUm1mCKv+KUZyDUUmY98wVoCk8mXklcJteAR3BBHTE5UNgR5QkIqSkGhhNClb5nfc+ +Xvp5C/VB5ZETTjtFtGo+cwv3ty24Iclp+ato0Fs+/wyt8UmzT8/hTueg+G4stjV3SdMc1J9B W/PkS5m4Inm+yDyNDzxY9V5vYeTsm4y7Flpl5izsnpe/ClXpYC2K90RN9nnNcZvmd4R8zY7sf D0ra9FDOby57aKT5JPNWfOr1BiKc5INNRiLipOBAA2j6I2EwMAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1461573105!37560268!1 X-Originating-IP: [74.125.82.49] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 35754 invoked from network); 25 Apr 2016 08:31:45 -0000 Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by server-12.tower-27.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 25 Apr 2016 08:31:45 -0000 Received: by mail-wm0-f49.google.com with SMTP id u206so114673138wme.1 for ; Mon, 25 Apr 2016 01:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=MCa1ZCzDWkIxn4te59VnoyyUtyn7JwjlULVuNgSU/yE=; b=sdjgusOkDTBFPw6NW/w4fpvZFfS6/UTRaLT6tuQKfx5QmGaxtefvzBAdBITgozsvqz z+0u8//Hh9PZLZ8BffZoVPKX04saoJ5jrKa+07VaU7eBBWlJZbssKztNGf75WJGsUAAE P0SBTJ/4AHk8Az6VwULM5q4D1ANPMrCM3FZqLb8tB1FiMOxG0X8MgFcjxajLAP4s6xEN Mzxxlv+KLOer5tEBHWiofDGTuvkX91pw7SoS9Ls7nZr9TQneu+1WYr3b3od1/LFLp/sh avcwDdRgjt4Z1r3rKN77eRIP28JV5KG1/S9ZKCTrDpbh9d+w/rrIkbL6xj91WCBInz5u m41Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MCa1ZCzDWkIxn4te59VnoyyUtyn7JwjlULVuNgSU/yE=; b=SDg3hN46ztIm0miX5mRLqYlYJOHzu3Hc9/MSXDx6aFV2sIXIuZZZ6kVcaLHvThNiLP WyZ4HKKjBa5acGOaslBU3bBbQtaoa+gZhFh8zLBSH6WI4Sz1TduWJnf8F0Q2vgSKNw0R xGtDuSahqib3D6xJxdPFb4vl/aOEmU7auC7GzlFwtjQd7vdR5Iyz9NCwS48qebNuMXbi /9K+xS+nlNAtQeqXzhTzWghhkmn2hjCa2b+C1CfqEJoaPV63FLUFUbNejUl4gh4Kwb+A hObt3UgxwrZBhNnmjrlU5cg1LDCDKFpr9NBlC6SdJH6ifGJs7B4fsw2hNSVAuvQPg+X/ tBMg== X-Gm-Message-State: AOPr4FWX0zUb6bKc2+M3ylhQItCKmGqP/TMf5RyF4zby+eqE40Y0bNichE66P8XSxh7M5A== X-Received: by 10.194.77.42 with SMTP id p10mr32581356wjw.111.1461573105197; Mon, 25 Apr 2016 01:31:45 -0700 (PDT) Received: from [192.168.0.9] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id s10sm22404612wjp.3.2016.04.25.01.31.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 01:31:43 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Mon, 25 Apr 2016 09:31:42 +0100 Message-Id: References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> To: Zibby Keaton X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , appointments@xenproject.org, publicity@lists.xenproject.org, George Dunlap Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============8390253064433022678==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============8390253064433022678== Content-Type: multipart/alternative; boundary="Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A" --Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adding George's work e-mail address=20 I am not sure whether we want to draw the attention of reporters to = this, because there is a risk that they turn this into a negative story. However, we also need to write and publish an Hackathon write-up report. And we should welcome our Outreachy participants and also mention GSoC = students working on Xen (even though the participant is technically = working on a FreeBSD project) Regards=20 Lars > On 22 Apr 2016, at 20:48, Zibby Keaton = wrote: >=20 > Hi all - >=20 > I just spoke with Lars about this via Skype and I think there's = potential for this to be a story that we present to the media. It shows = that you are growing and evolving as a community. Next week is the = OpenStack Summit and most of our reporters will be covering the news = coming out of the conference. >=20 > So we don't get drowned out in noise, I suggest we publish this week = of May 2nd. Sarah and I will work on media strategy here and update the = copy appropriately. >=20 > I want to make sure that everyone is in the loop and knows what's = happening next.=20 >=20 > Let me know if you have any questions or concerns. >=20 > Zibby >=20 > On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth > wrote: >=20 > > On 22 Apr 2016, at 19:48, Lars Kurth > wrote: > > > > See https://blog.xenproject.org/?p=3D11310&preview=3Dtrue = > > I would like to publish on Monday > > > > Those on the CC list: I made up some short bios for each of you, = based on what I know. Feel free to suggest corrections/additions. > > > > @Zibby: could you go through this with a view towards media impact = (e.g. a possibly negative register story). We are intentionally not = stating company affiliation. > > > > Lars >=20 >=20 > I added the text (unformatted) for convenience > Lars >=20 > --- >=20 > A couple of months ago two of our committers, Keir Fraser and Tim = Deegan, have formally stepped down in their roles as committers from the = Hypervisor team, while others have changed their focus or level of = involvement in the project. > Unfortunately, the project has found it difficult to promote = contributors to maintainer andcommitter roles, which constitute the = leadership of the Xen Project Hypervisor Team. This was true, despite an = actively growing community (see diagram on the right). >=20 > After some soul searching, we realised that the primary reason for = this issue was not that we didn=E2=80=99t have future leaders within the = community. The issue was simply that we didn=E2=80=99t have an organised = approach to succession planning: active developers simply worked on the = project and did not consider to nominate newcomers (or themselves) for = leadership roles within the project. To fix this, we introduced a new = convention, by which we actively remind community members to nominate or = self-nominate themselves for leadership roles. >=20 > This approach has worked very well, and I am pleased to announce the = following new members to the Xen Project Hypervisor Leadership Team. = However, before doing so, I wanted to thank Keir and Tim for their vast = contributions to the project. >=20 > Committers >=20 > The following people have been elected to be new Committers to the = project, alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad = Rzeszutek Wilk: >=20 > Andrew Cooper has been working on the Hypervisor since 2011 and has = added a number of major new features such as Migration v2, significant = change to trap handling, improvements to cpuid handling for guests and = many more. >=20 > George Dunlap has been working on the Hypervisor since 2008 and was = heavily involved in making the tracing system useable for > performance analysis, optimising the shadow code, wrote the credit2 = scheduler and developed many other significant features and improvements = in the hypervisor. In addition, he was our first Release Manager and is = leading the CentOS Virtualisation SIG within CentOS. >=20 > Stefano Stabellini has been working on the Hypervisor and the Linux = Kernel since 2008 and was instrumental in bringing ARM support to the = Xen Hypervisor. He has also been leading many other activities within = the project, such as OpenStack integration and Raisin. >=20 > Wei Liu started to work on the Xen Project as a GSoC student in 2011 = (working in virtio support). He has been working on libxl support, event = channel scalability, MiniOS and many other major Xen features. In = addition he has been the Xen Project Release Manager since Xen Project = 4.6 release. >=20 > Andrew and Wei celebrated their appointment at one of the Xen Project = social events earlier this week, by submitting and ACKing a piece of = code while on a punt on the river Cam in Cambridge, UK. >=20 >=20 > Security Team >=20 > In addition, Andrew Cooper and George Dunlap are now also members of = the Xen Project Security Team, alongside Ian Jackson, Jan Beulich and = Tim Deegan. >=20 > Maintainers >=20 > The following people were also recently added as MAINTAINERS of the = project: Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, = device tree, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 = I/O emulation, x86 viridian enlightenments, =E2=80=A6). In addition, we = clarified some ambiguities around the maintainer role. >=20 > Linux Kernel Maintainers >=20 > J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since = 2004, but has significantly increased his engagement within the = community in the last two years, and is now Linux Kernel maintainer for = the Xen Hypervisor Interface alongside Boris Ostrovsky and David Vrabel. = Other maintainers of Xen specific components in the Linux Kernel are: = Stefano Stabellini, Wei Lui, and Konrad Rzeszutek Wilk. >=20 >=20 >=20 > --=20 > Zibby Keaton > The Linux Foundation > PR Manager > 208-290-4853 > zkeaton@linuxfoundation.org > Skype: zibby.keaton > Twitter: ZibbyK --Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adding George's work e-mail address 

I am not sure whether we want to draw the = attention of reporters to this, because there is a risk that they turn = this into a negative story.

However, we also need to write and publish an Hackathon = write-up report.
And we should welcome our = Outreachy participants and also mention GSoC students working on Xen = (even though the participant is technically working on a FreeBSD = project)

Regards 
Lars

On 22 Apr 2016, at 20:48, Zibby Keaton <zkeaton@linuxfoundation.org> wrote:

Hi all -

I = just spoke with Lars about this via Skype and I think there's potential = for this to be a story that we present to the media. It shows that you = are growing and evolving as a community. Next week is the OpenStack = Summit and most of our reporters will be covering the news coming out of = the conference.

So we don't get drowned out in noise, I suggest we publish = this week of May 2nd. Sarah and I will work on media strategy here and = update the copy appropriately.

I want to make sure that everyone is in = the loop and knows what's happening next. 

Let me know if you have any questions = or concerns.

Zibby

On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth <lars.kurth.xen@gmail.com> = wrote:

> On 22 Apr 2016, at 19:48, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
>
> See https://blog.xenproject.org/?p=3D11310&preview=3Dtrue > I would like to publish on Monday
>
> Those on the CC list: I made up some short bios for each of you, = based on what I know. Feel free to suggest corrections/additions.
>
> @Zibby: could you go through this with a view towards media impact = (e.g. a possibly negative register story). We are intentionally not = stating company affiliation.
>
> Lars


I added the text (unformatted) for convenience
Lars

---

A couple of months ago two of our committers, Keir Fraser and Tim = Deegan, have formally stepped down in their roles as committers from the = Hypervisor team, while others have changed their focus or level of = involvement in the project.
Unfortunately, the project has found it difficult to promote = contributors to maintainer andcommitter roles, which constitute the = leadership of the Xen Project Hypervisor Team. This was true, despite an = actively growing community (see diagram on the right).

After some soul searching, we realised that the primary reason for this = issue was not that we didn=E2=80=99t have future leaders within the = community. The issue was simply that we didn=E2=80=99t have an organised = approach to succession planning: active developers simply worked on the = project and did not consider to nominate newcomers (or themselves) for = leadership roles within the project. To fix this, we introduced a new = convention, by which we actively remind community members to nominate or = self-nominate themselves for leadership roles.

This approach has worked very well, and I am pleased to announce the = following new members to the Xen Project Hypervisor Leadership Team. = However, before doing so, I wanted to thank Keir and Tim for their vast = contributions to the project.

Committers

The following people have been elected to be new Committers to the = project, alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad = Rzeszutek Wilk:

Andrew Cooper has been working on the Hypervisor since 2011 and has = added a number of major new features such as Migration v2, significant = change to trap handling, improvements to cpuid handling for guests and = many more.

George Dunlap has been working on the Hypervisor since 2008 and was = heavily involved in making the tracing system useable for
performance analysis, optimising the shadow code, wrote the credit2 = scheduler and developed many other significant features and improvements = in the hypervisor. In addition, he was our first Release Manager and is = leading the CentOS Virtualisation SIG within CentOS.

Stefano Stabellini has been working on the Hypervisor and the Linux = Kernel since 2008 and was instrumental in bringing ARM support to the = Xen Hypervisor. He has also been leading many other activities within = the project, such as OpenStack integration and Raisin.

Wei Liu started to work on the Xen Project as a GSoC student in 2011 = (working in virtio support). He has been working on libxl support, event = channel scalability, MiniOS and many other major Xen features. In = addition he has been the Xen Project Release Manager since Xen Project = 4.6 release.

Andrew and Wei celebrated their appointment at one of the Xen Project = social events earlier this week, by submitting and ACKing a piece of = code while on a punt on the river Cam in Cambridge, UK.


Security Team

In addition, Andrew Cooper and George Dunlap are now also members of the = Xen Project Security Team, alongside Ian Jackson, Jan Beulich and Tim = Deegan.

Maintainers

The following people were also recently added as MAINTAINERS of the = project: Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, = device tree, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 = I/O emulation, x86 viridian enlightenments, =E2=80=A6). In addition, we = clarified some ambiguities around the maintainer role.

Linux Kernel Maintainers

J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since = 2004, but has significantly increased his engagement within the = community in the last two years, and is now Linux Kernel maintainer for = the Xen Hypervisor Interface alongside Boris Ostrovsky and David Vrabel. = Other maintainers of Xen specific components in the Linux Kernel are: = Stefano Stabellini, Wei Lui, and Konrad Rzeszutek = Wilk.



--
Zibby Keaton
The Linux = Foundation
PR Manager
208-290-4853
zkeaton@linuxfoundation.org
Skype: = zibby.keaton
Twitter: = ZibbyK

= --Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A-- --===============8390253064433022678== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============8390253064433022678==-- From publicity-bounces@lists.xenproject.org Mon Apr 25 08:31:50 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 Apr 2016 08:31:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aubvp-0003Fp-1t; Mon, 25 Apr 2016 08:31:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aubvn-0003Fj-Up for publicity@lists.xenproject.org; Mon, 25 Apr 2016 08:31:48 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id FD/FB-02914-3F5DD175; Mon, 25 Apr 2016 08:31:47 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleJIrShJLcpLzFFi42Lxqg0y1P14VTb cYPEnNYvffWsZHRg9Dn+4whLAGMWamZeUX5HAmnH18k3Ggs6qiuddt1kaGHdmdDFycQgJzGKU WHb3HguIwyLQwCpxYddnNhBHQmAOq8SmR6uAMpxAToxE7+0f7BB2lcTDzxuZQWwhAXWJe4tus 0OM+sIocWP6FFaQBLNAgsSpq7/AmnkF9CRe3boMFhcWSJJ4dvUHI4jNJqAtsenGA6BBHBycAo ES81fZgIRZBFQljkyaywQyk1lgPpNE5/olzBBzbCQWPlnKBrFsE6PEhP1r2EASIkALDrScZ4a 4TlZi9+9HTBMYhWYhuWMWkjsg4toSyxa+Zp4FtJtZQENi6+VkVGEQW13i6tqrrAsY2VYxqhen FpWlFuma6yUVZaZnlOQmZuboGhqa6OWmFhcnpqfmJCYV6yXn525iBMYGAxDsYPyyxPkQoyQHk 5Io78lDsuFCfEn5KZUZicUZ8UWlOanFhxhlODiUJHgZgbEmJFiUmp5akZaZA4xSmLQEB4+SCO +cS0Bp3uKCxNzizHSI1ClGXY4tU++tZRJiycvPS5US5xUAmSEAUpRRmgc3ApYwLjHKSgnzMgI dJcRTkFqUm1mCKv+KUZyDUUmY98wVoCk8mXklcJteAR3BBHTE5UNgR5QkIqSkGhhNClb5nfc+ +Xvp5C/VB5ZETTjtFtGo+cwv3ty24Iclp+ato0Fs+/wyt8UmzT8/hTueg+G4stjV3SdMc1J9B W/PkS5m4Inm+yDyNDzxY9V5vYeTsm4y7Flpl5izsnpe/ClXpYC2K90RN9nnNcZvmd4R8zY7sf D0ra9FDOby57aKT5JPNWfOr1BiKc5INNRiLipOBAA2j6I2EwMAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1461573105!37560268!1 X-Originating-IP: [74.125.82.49] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 35754 invoked from network); 25 Apr 2016 08:31:45 -0000 Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by server-12.tower-27.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 25 Apr 2016 08:31:45 -0000 Received: by mail-wm0-f49.google.com with SMTP id u206so114673138wme.1 for ; Mon, 25 Apr 2016 01:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=MCa1ZCzDWkIxn4te59VnoyyUtyn7JwjlULVuNgSU/yE=; b=sdjgusOkDTBFPw6NW/w4fpvZFfS6/UTRaLT6tuQKfx5QmGaxtefvzBAdBITgozsvqz z+0u8//Hh9PZLZ8BffZoVPKX04saoJ5jrKa+07VaU7eBBWlJZbssKztNGf75WJGsUAAE P0SBTJ/4AHk8Az6VwULM5q4D1ANPMrCM3FZqLb8tB1FiMOxG0X8MgFcjxajLAP4s6xEN Mzxxlv+KLOer5tEBHWiofDGTuvkX91pw7SoS9Ls7nZr9TQneu+1WYr3b3od1/LFLp/sh avcwDdRgjt4Z1r3rKN77eRIP28JV5KG1/S9ZKCTrDpbh9d+w/rrIkbL6xj91WCBInz5u m41Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MCa1ZCzDWkIxn4te59VnoyyUtyn7JwjlULVuNgSU/yE=; b=SDg3hN46ztIm0miX5mRLqYlYJOHzu3Hc9/MSXDx6aFV2sIXIuZZZ6kVcaLHvThNiLP WyZ4HKKjBa5acGOaslBU3bBbQtaoa+gZhFh8zLBSH6WI4Sz1TduWJnf8F0Q2vgSKNw0R xGtDuSahqib3D6xJxdPFb4vl/aOEmU7auC7GzlFwtjQd7vdR5Iyz9NCwS48qebNuMXbi /9K+xS+nlNAtQeqXzhTzWghhkmn2hjCa2b+C1CfqEJoaPV63FLUFUbNejUl4gh4Kwb+A hObt3UgxwrZBhNnmjrlU5cg1LDCDKFpr9NBlC6SdJH6ifGJs7B4fsw2hNSVAuvQPg+X/ tBMg== X-Gm-Message-State: AOPr4FWX0zUb6bKc2+M3ylhQItCKmGqP/TMf5RyF4zby+eqE40Y0bNichE66P8XSxh7M5A== X-Received: by 10.194.77.42 with SMTP id p10mr32581356wjw.111.1461573105197; Mon, 25 Apr 2016 01:31:45 -0700 (PDT) Received: from [192.168.0.9] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id s10sm22404612wjp.3.2016.04.25.01.31.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 01:31:43 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: Date: Mon, 25 Apr 2016 09:31:42 +0100 Message-Id: References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> To: Zibby Keaton X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , appointments@xenproject.org, publicity@lists.xenproject.org, George Dunlap Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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="===============8390253064433022678==" Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" --===============8390253064433022678== Content-Type: multipart/alternative; boundary="Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A" --Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adding George's work e-mail address=20 I am not sure whether we want to draw the attention of reporters to = this, because there is a risk that they turn this into a negative story. However, we also need to write and publish an Hackathon write-up report. And we should welcome our Outreachy participants and also mention GSoC = students working on Xen (even though the participant is technically = working on a FreeBSD project) Regards=20 Lars > On 22 Apr 2016, at 20:48, Zibby Keaton = wrote: >=20 > Hi all - >=20 > I just spoke with Lars about this via Skype and I think there's = potential for this to be a story that we present to the media. It shows = that you are growing and evolving as a community. Next week is the = OpenStack Summit and most of our reporters will be covering the news = coming out of the conference. >=20 > So we don't get drowned out in noise, I suggest we publish this week = of May 2nd. Sarah and I will work on media strategy here and update the = copy appropriately. >=20 > I want to make sure that everyone is in the loop and knows what's = happening next.=20 >=20 > Let me know if you have any questions or concerns. >=20 > Zibby >=20 > On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth > wrote: >=20 > > On 22 Apr 2016, at 19:48, Lars Kurth > wrote: > > > > See https://blog.xenproject.org/?p=3D11310&preview=3Dtrue = > > I would like to publish on Monday > > > > Those on the CC list: I made up some short bios for each of you, = based on what I know. Feel free to suggest corrections/additions. > > > > @Zibby: could you go through this with a view towards media impact = (e.g. a possibly negative register story). We are intentionally not = stating company affiliation. > > > > Lars >=20 >=20 > I added the text (unformatted) for convenience > Lars >=20 > --- >=20 > A couple of months ago two of our committers, Keir Fraser and Tim = Deegan, have formally stepped down in their roles as committers from the = Hypervisor team, while others have changed their focus or level of = involvement in the project. > Unfortunately, the project has found it difficult to promote = contributors to maintainer andcommitter roles, which constitute the = leadership of the Xen Project Hypervisor Team. This was true, despite an = actively growing community (see diagram on the right). >=20 > After some soul searching, we realised that the primary reason for = this issue was not that we didn=E2=80=99t have future leaders within the = community. The issue was simply that we didn=E2=80=99t have an organised = approach to succession planning: active developers simply worked on the = project and did not consider to nominate newcomers (or themselves) for = leadership roles within the project. To fix this, we introduced a new = convention, by which we actively remind community members to nominate or = self-nominate themselves for leadership roles. >=20 > This approach has worked very well, and I am pleased to announce the = following new members to the Xen Project Hypervisor Leadership Team. = However, before doing so, I wanted to thank Keir and Tim for their vast = contributions to the project. >=20 > Committers >=20 > The following people have been elected to be new Committers to the = project, alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad = Rzeszutek Wilk: >=20 > Andrew Cooper has been working on the Hypervisor since 2011 and has = added a number of major new features such as Migration v2, significant = change to trap handling, improvements to cpuid handling for guests and = many more. >=20 > George Dunlap has been working on the Hypervisor since 2008 and was = heavily involved in making the tracing system useable for > performance analysis, optimising the shadow code, wrote the credit2 = scheduler and developed many other significant features and improvements = in the hypervisor. In addition, he was our first Release Manager and is = leading the CentOS Virtualisation SIG within CentOS. >=20 > Stefano Stabellini has been working on the Hypervisor and the Linux = Kernel since 2008 and was instrumental in bringing ARM support to the = Xen Hypervisor. He has also been leading many other activities within = the project, such as OpenStack integration and Raisin. >=20 > Wei Liu started to work on the Xen Project as a GSoC student in 2011 = (working in virtio support). He has been working on libxl support, event = channel scalability, MiniOS and many other major Xen features. In = addition he has been the Xen Project Release Manager since Xen Project = 4.6 release. >=20 > Andrew and Wei celebrated their appointment at one of the Xen Project = social events earlier this week, by submitting and ACKing a piece of = code while on a punt on the river Cam in Cambridge, UK. >=20 >=20 > Security Team >=20 > In addition, Andrew Cooper and George Dunlap are now also members of = the Xen Project Security Team, alongside Ian Jackson, Jan Beulich and = Tim Deegan. >=20 > Maintainers >=20 > The following people were also recently added as MAINTAINERS of the = project: Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, = device tree, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 = I/O emulation, x86 viridian enlightenments, =E2=80=A6). In addition, we = clarified some ambiguities around the maintainer role. >=20 > Linux Kernel Maintainers >=20 > J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since = 2004, but has significantly increased his engagement within the = community in the last two years, and is now Linux Kernel maintainer for = the Xen Hypervisor Interface alongside Boris Ostrovsky and David Vrabel. = Other maintainers of Xen specific components in the Linux Kernel are: = Stefano Stabellini, Wei Lui, and Konrad Rzeszutek Wilk. >=20 >=20 >=20 > --=20 > Zibby Keaton > The Linux Foundation > PR Manager > 208-290-4853 > zkeaton@linuxfoundation.org > Skype: zibby.keaton > Twitter: ZibbyK --Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adding George's work e-mail address 

I am not sure whether we want to draw the = attention of reporters to this, because there is a risk that they turn = this into a negative story.

However, we also need to write and publish an Hackathon = write-up report.
And we should welcome our = Outreachy participants and also mention GSoC students working on Xen = (even though the participant is technically working on a FreeBSD = project)

Regards 
Lars

On 22 Apr 2016, at 20:48, Zibby Keaton <zkeaton@linuxfoundation.org> wrote:

Hi all -

I = just spoke with Lars about this via Skype and I think there's potential = for this to be a story that we present to the media. It shows that you = are growing and evolving as a community. Next week is the OpenStack = Summit and most of our reporters will be covering the news coming out of = the conference.

So we don't get drowned out in noise, I suggest we publish = this week of May 2nd. Sarah and I will work on media strategy here and = update the copy appropriately.

I want to make sure that everyone is in = the loop and knows what's happening next. 

Let me know if you have any questions = or concerns.

Zibby

On Fri, Apr 22, 2016 at 2:49 PM, Lars Kurth <lars.kurth.xen@gmail.com> = wrote:

> On 22 Apr 2016, at 19:48, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
>
> See https://blog.xenproject.org/?p=3D11310&preview=3Dtrue > I would like to publish on Monday
>
> Those on the CC list: I made up some short bios for each of you, = based on what I know. Feel free to suggest corrections/additions.
>
> @Zibby: could you go through this with a view towards media impact = (e.g. a possibly negative register story). We are intentionally not = stating company affiliation.
>
> Lars


I added the text (unformatted) for convenience
Lars

---

A couple of months ago two of our committers, Keir Fraser and Tim = Deegan, have formally stepped down in their roles as committers from the = Hypervisor team, while others have changed their focus or level of = involvement in the project.
Unfortunately, the project has found it difficult to promote = contributors to maintainer andcommitter roles, which constitute the = leadership of the Xen Project Hypervisor Team. This was true, despite an = actively growing community (see diagram on the right).

After some soul searching, we realised that the primary reason for this = issue was not that we didn=E2=80=99t have future leaders within the = community. The issue was simply that we didn=E2=80=99t have an organised = approach to succession planning: active developers simply worked on the = project and did not consider to nominate newcomers (or themselves) for = leadership roles within the project. To fix this, we introduced a new = convention, by which we actively remind community members to nominate or = self-nominate themselves for leadership roles.

This approach has worked very well, and I am pleased to announce the = following new members to the Xen Project Hypervisor Leadership Team. = However, before doing so, I wanted to thank Keir and Tim for their vast = contributions to the project.

Committers

The following people have been elected to be new Committers to the = project, alongside Ian Campbell, Ian Jackson, Jan Beulich and Konrad = Rzeszutek Wilk:

Andrew Cooper has been working on the Hypervisor since 2011 and has = added a number of major new features such as Migration v2, significant = change to trap handling, improvements to cpuid handling for guests and = many more.

George Dunlap has been working on the Hypervisor since 2008 and was = heavily involved in making the tracing system useable for
performance analysis, optimising the shadow code, wrote the credit2 = scheduler and developed many other significant features and improvements = in the hypervisor. In addition, he was our first Release Manager and is = leading the CentOS Virtualisation SIG within CentOS.

Stefano Stabellini has been working on the Hypervisor and the Linux = Kernel since 2008 and was instrumental in bringing ARM support to the = Xen Hypervisor. He has also been leading many other activities within = the project, such as OpenStack integration and Raisin.

Wei Liu started to work on the Xen Project as a GSoC student in 2011 = (working in virtio support). He has been working on libxl support, event = channel scalability, MiniOS and many other major Xen features. In = addition he has been the Xen Project Release Manager since Xen Project = 4.6 release.

Andrew and Wei celebrated their appointment at one of the Xen Project = social events earlier this week, by submitting and ACKing a piece of = code while on a punt on the river Cam in Cambridge, UK.


Security Team

In addition, Andrew Cooper and George Dunlap are now also members of the = Xen Project Security Team, alongside Ian Jackson, Jan Beulich and Tim = Deegan.

Maintainers

The following people were also recently added as MAINTAINERS of the = project: Doug Goldstein(KConfig, Travis CI), Julien Grall (ARM support, = device tree, =E2=80=A6), Meng Xu (RTDS Scheduler) andPaul Durrant (x86 = I/O emulation, x86 viridian enlightenments, =E2=80=A6). In addition, we = clarified some ambiguities around the maintainer role.

Linux Kernel Maintainers

J=C3=BCrgen Gross who has been a Linux kernel and Xen developer since = 2004, but has significantly increased his engagement within the = community in the last two years, and is now Linux Kernel maintainer for = the Xen Hypervisor Interface alongside Boris Ostrovsky and David Vrabel. = Other maintainers of Xen specific components in the Linux Kernel are: = Stefano Stabellini, Wei Lui, and Konrad Rzeszutek = Wilk.



--
Zibby Keaton
The Linux = Foundation
PR Manager
208-290-4853
zkeaton@linuxfoundation.org
Skype: = zibby.keaton
Twitter: = ZibbyK

= --Apple-Mail=_1438D7B2-58E8-4F2C-8A28-E6580297B47A-- --===============8390253064433022678== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5 IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3Rz LnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK --===============8390253064433022678==-- From publicity-bounces@lists.xenproject.org Mon Apr 25 08:38:56 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 Apr 2016 08:38:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1auc2h-0003Wp-Vk; Mon, 25 Apr 2016 08:38:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1auc2h-0003Wg-2r for publicity@lists.xenproject.org; Mon, 25 Apr 2016 08:38:55 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id 30/E3-03294-E97DD175; Mon, 25 Apr 2016 08:38:54 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRWlGSWpSXmKPExsXiVRtkpDv3umy 4wY6Pkha/+9YyOjB6HP5whSWAMYo1My8pvyKBNePZ1Q1sBTt4K/raehgbGDu5uxi5OIQEZjBK 3L98mRHEYRGYxSpxq+UZK4gjIbCNVeLv/4dMXYycQE6MxPWZvewQdqXE3/tPWEBsIQF1iXuLb rNDjPrKKNHz7S1YEbOAlsSNfy/BmnkF9CRe3brMCmILCyRJPLv6gxHEZhPQlth04wEziM0pYC /RvmkKWxcjB9AZqhLX1zlCjDnDJPHiowqErS2xbOFrZpASXgEbiT//KiDWLmCUmHd0JxtIjYi AskTvr98sEHfKSuz+/YhpAqPwLCQXzUJy0SwkYxcwMq9iVC9OLSpLLdI11ksqykzPKMlNzMzR NTQw1stNLS5OTE/NSUwq1kvOz93ECAx0BiDYwdj8xekQoyQHk5Io78lDsuFCfEn5KZUZicUZ8 UWlOanFhxhlODiUJHhzrgHlBItS01Mr0jJzgDEHk5bg4FES4Z1zCSjNW1yQmFucmQ6ROsWoy7 Fl6r21TEIsefl5qVLivIwgMwRAijJK8+BGwOL/EqOslDAvI9BRQjwFqUW5mSWo8q8YxTkYlYR 5S0Cm8GTmlcBtegV0BBPQEZcPgR1RkoiQkmpgLH5b2/JaZup72/zwINUb+ntebznDKXz59+qE 2O9durNvFhy89uvZhyNzpu1Ye3K2bFnMgh9lnA55/b8+Xar+VFH8JqZ82YReDuZlXJdncJxYY rhqeVnW33eJkSsPP+BjevJxLYvB8UmOqtZz3wlsu3T1yeMtF36X7hFxKf+6mF9E3pzdXvv97P tKLMUZiYZazEXFiQDBEDoO+gIAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1461573533!29179668!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 53653 invoked from network); 25 Apr 2016 08:38:53 -0000 Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by server-16.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 25 Apr 2016 08:38:53 -0000 Received: by mail-wm0-f50.google.com with SMTP id n3so115334954wmn.0 for ; Mon, 25 Apr 2016 01:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h8bCfME0yrOyaPZhUaV/XssiTRDL/bEtI1pF//c7Cck=; b=sd6uwjbe86NcwvSD2/YTzcrp9ymjub43zvayc50xvf/YP0EddpTkMZ+ljHlCFIzQwI 7FBGl5ZOJOyDn0W7T/f/QpC33NaObqTSDJZhIgHUk6WZf4SNG6VJBnPD/6fJWZr4VHCg sjzhg6+F2PioqU2Nsnsq5g2hztbxuY9Y1OyLLlBtoIB+wnTYewJ7SNy1qcO+z1Vzxf2y 2ok3EDHfvYRGUHghFMfnQ8t8wU6HRGJvxsvXmKfqzqMsDqg+NKoomLEZ3TopLldGRci3 6ztB58mnd9E2PPBnuDnB7frm49baxmxeY/ztL8xLqQ/w4IZVeL33rRLMlYkQXJXVbvb+ aK1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h8bCfME0yrOyaPZhUaV/XssiTRDL/bEtI1pF//c7Cck=; b=lHfnRYfgioVGODqGLcejuedOvsKYqh3kqLu3KTc8OgHhTaMsXIzzE/0Qcg9Af7TP7I 99o7fGe2b03kEMnuTvB9bXj85EhcoKrXqknsTrKZchFd2NpWkSRW2RZeAnz1aW7G0PX0 /WEP8bZsJeNNR9vrsPASjLBjPBpST0gzCLqther+E0Po1Gruqj1sAZlC2Mad0DKHB+8X LuI5++Yv52fSXC9ObFTiT3RMxIG/A0RWyAiAGzlOhq8FHwEXSrW3ksVV3KD8gMAe+idy UEGWwYzs8S3hZjIapoufAQjpBUHinFJEg2njeQ2yiuldtTPbDa2sWRaJgfZMNdy7mR6M 4Zfg== X-Gm-Message-State: AOPr4FX/DooW/7b6+bm99W7jKeLK1izpw4Rf23GOH60/FffnANfiGjKFKlnLxxslYV9jOw== X-Received: by 10.194.82.168 with SMTP id j8mr37994183wjy.37.1461573532952; Mon, 25 Apr 2016 01:38:52 -0700 (PDT) Received: from [192.168.0.9] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id ki9sm22438356wjb.37.2016.04.25.01.38.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 01:38:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: <571DE6AC02000078000E5238@prv-mh.provo.novell.com> Date: Mon, 25 Apr 2016 09:38:50 +0100 Message-Id: <3FEFAB8B-E9FA-4B7E-9767-B2FBB11BC88B@gmail.com> References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> <571DE6AC02000078000E5238@prv-mh.provo.novell.com> To: Jan Beulich X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , appointments@xenproject.org, publicity@lists.xenproject.org, George Dunlap , Zibby Keaton Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" Cj4gT24gMjUgQXByIDIwMTYsIGF0IDA4OjQzLCBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5j b20+IHdyb3RlOgo+IAo+Pj4+IE9uIDIyLjA0LjE2IGF0IDIwOjQ5LCA8bGFycy5rdXJ0aC54ZW5A Z21haWwuY29tPiB3cm90ZToKPj4gQ29tbWl0dGVycwo+PiAKPj4gVGhlIGZvbGxvd2luZyBwZW9w bGUgaGF2ZSBiZWVuIGVsZWN0ZWQgdG8gYmUgbmV3IENvbW1pdHRlcnMgdG8gdGhlIHByb2plY3Qs IAo+PiBhbG9uZ3NpZGUgSWFuIENhbXBiZWxsLCBJYW4gSmFja3NvbiwgSmFuIEJldWxpY2ggYW5k IEtvbnJhZCBSemVzenV0ZWsgV2lsazoKPj4gCj4+IEFuZHJldyBDb29wZXIgaGFzIGJlZW4gd29y a2luZyBvbiB0aGUgSHlwZXJ2aXNvciBzaW5jZSAyMDExIGFuZCBoYXMgYWRkZWQgYSAKPj4gbnVt YmVyIG9mIG1ham9yIG5ldyBmZWF0dXJlcyBzdWNoIGFzIE1pZ3JhdGlvbiB2Miwgc2lnbmlmaWNh bnQgY2hhbmdlIHRvIHRyYXAgCj4+IGhhbmRsaW5nLCBpbXByb3ZlbWVudHMgdG8gY3B1aWQgaGFu ZGxpbmcgZm9yIGd1ZXN0cyBhbmQgbWFueSBtb3JlLgo+PiAKPj4gR2VvcmdlIER1bmxhcCBoYXMg YmVlbiB3b3JraW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMDggYW5kIHdhcyBoZWF2aWx5 IAo+PiBpbnZvbHZlZCBpbiBtYWtpbmcgdGhlIHRyYWNpbmcgc3lzdGVtIHVzZWFibGUgZm9yCj4+ IHBlcmZvcm1hbmNlIGFuYWx5c2lzLCBvcHRpbWlzaW5nIHRoZSBzaGFkb3cgY29kZSwgd3JvdGUg dGhlIGNyZWRpdDIgCj4+IHNjaGVkdWxlciBhbmQgZGV2ZWxvcGVkIG1hbnkgb3RoZXIgc2lnbmlm aWNhbnQgZmVhdHVyZXMgYW5kIGltcHJvdmVtZW50cyBpbiAKPj4gdGhlIGh5cGVydmlzb3IuIElu IGFkZGl0aW9uLCBoZSB3YXMgb3VyIGZpcnN0IFJlbGVhc2UgTWFuYWdlciBhbmQgaXMgbGVhZGlu ZyAKPj4gdGhlIENlbnRPUyBWaXJ0dWFsaXNhdGlvbiBTSUcgd2l0aGluIENlbnRPUy4KPiAKPiBT aG91bGRuJ3QgeW91LCBqdXN0IGxpa2UgeW91IGRvIGZvciBXZWksIG1lbnRpb24gR2VvcmdlJ3Mg cm9sZSBhcwo+IHJlbGVhc2UgbWFuYWdlciAoSSBhZG1pdCBJIGRvbid0IHJlY2FsbCBmb3Igd2hp Y2ggdmVyc2lvbihzKSB0aGlzIHdhcyk/CgpJIHRob3VnaHQgSSBtZW50aW9uZWQgaXQuIElkZWFs bHksIGVhY2ggbmV3IGNvbW1pdHRlciB3b3VsZCBoaWdobGlnaHQgdGhlIHRoaW5ncyB0aGF0IHRo ZXkgdGhpbmsgc2hvdWxkIGJlIGhpZ2hsaWdodGVkLiAgCgpXZSBoYXZlIGEgYml0IG1vcmUgdGlt ZSBub3csIGlmIHdlIHdhaXQgdGlsbCBuZXh0IE1vbmRheSwgYXMgU2FyYWggc3VnZ2VzdGVkLgoK Pj4gU2VjdXJpdHkgVGVhbQo+PiAKPj4gSW4gYWRkaXRpb24sIEFuZHJldyBDb29wZXIgYW5kIEdl b3JnZSBEdW5sYXAgYXJlIG5vdyBhbHNvIG1lbWJlcnMgb2YgdGhlIFhlbiAKPj4gUHJvamVjdCBT ZWN1cml0eSBUZWFtLCBhbG9uZ3NpZGUgSWFuIEphY2tzb24sIEphbiBCZXVsaWNoIGFuZCBUaW0g RGVlZ2FuLgo+IAo+IC4uLiBhbmQgS29ucmFkLgoKQXBvbG9naWVzLCBJIG1pc3NlZCBoaW0uCgpJ IHdvbmRlciB3aGV0aGVyIHdlIHNob3VsZCBhbHNvIG1lbnRpb24gb3VyIFFFTVUgYW5kIEJTRCBj b21taXR0ZXJzLCBidXQgYXMgZmFyIGFzIEkgcmVjYWxsIHRoZXJlIHdlcmUgbm8gY2hhbmdlcy4K CkxhcnMKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K UHVibGljaXR5IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNp dHkK From publicity-bounces@lists.xenproject.org Mon Apr 25 08:38:56 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 Apr 2016 08:38:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1auc2h-0003Wp-Vk; Mon, 25 Apr 2016 08:38:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1auc2h-0003Wg-2r for publicity@lists.xenproject.org; Mon, 25 Apr 2016 08:38:55 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id 30/E3-03294-E97DD175; Mon, 25 Apr 2016 08:38:54 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRWlGSWpSXmKPExsXiVRtkpDv3umy 4wY6Pkha/+9YyOjB6HP5whSWAMYo1My8pvyKBNePZ1Q1sBTt4K/raehgbGDu5uxi5OIQEZjBK 3L98mRHEYRGYxSpxq+UZK4gjIbCNVeLv/4dMXYycQE6MxPWZvewQdqXE3/tPWEBsIQF1iXuLb rNDjPrKKNHz7S1YEbOAlsSNfy/BmnkF9CRe3brMCmILCyRJPLv6gxHEZhPQlth04wEziM0pYC /RvmkKWxcjB9AZqhLX1zlCjDnDJPHiowqErS2xbOFrZpASXgEbiT//KiDWLmCUmHd0JxtIjYi AskTvr98sEHfKSuz+/YhpAqPwLCQXzUJy0SwkYxcwMq9iVC9OLSpLLdI11ksqykzPKMlNzMzR NTQw1stNLS5OTE/NSUwq1kvOz93ECAx0BiDYwdj8xekQoyQHk5Io78lDsuFCfEn5KZUZicUZ8 UWlOanFhxhlODiUJHhzrgHlBItS01Mr0jJzgDEHk5bg4FES4Z1zCSjNW1yQmFucmQ6ROsWoy7 Fl6r21TEIsefl5qVLivIwgMwRAijJK8+BGwOL/EqOslDAvI9BRQjwFqUW5mSWo8q8YxTkYlYR 5S0Cm8GTmlcBtegV0BBPQEZcPgR1RkoiQkmpgLH5b2/JaZup72/zwINUb+ntebznDKXz59+qE 2O9durNvFhy89uvZhyNzpu1Ye3K2bFnMgh9lnA55/b8+Xar+VFH8JqZ82YReDuZlXJdncJxYY rhqeVnW33eJkSsPP+BjevJxLYvB8UmOqtZz3wlsu3T1yeMtF36X7hFxKf+6mF9E3pzdXvv97P tKLMUZiYZazEXFiQDBEDoO+gIAAA== X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1461573533!29179668!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 53653 invoked from network); 25 Apr 2016 08:38:53 -0000 Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by server-16.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 25 Apr 2016 08:38:53 -0000 Received: by mail-wm0-f50.google.com with SMTP id n3so115334954wmn.0 for ; Mon, 25 Apr 2016 01:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h8bCfME0yrOyaPZhUaV/XssiTRDL/bEtI1pF//c7Cck=; b=sd6uwjbe86NcwvSD2/YTzcrp9ymjub43zvayc50xvf/YP0EddpTkMZ+ljHlCFIzQwI 7FBGl5ZOJOyDn0W7T/f/QpC33NaObqTSDJZhIgHUk6WZf4SNG6VJBnPD/6fJWZr4VHCg sjzhg6+F2PioqU2Nsnsq5g2hztbxuY9Y1OyLLlBtoIB+wnTYewJ7SNy1qcO+z1Vzxf2y 2ok3EDHfvYRGUHghFMfnQ8t8wU6HRGJvxsvXmKfqzqMsDqg+NKoomLEZ3TopLldGRci3 6ztB58mnd9E2PPBnuDnB7frm49baxmxeY/ztL8xLqQ/w4IZVeL33rRLMlYkQXJXVbvb+ aK1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h8bCfME0yrOyaPZhUaV/XssiTRDL/bEtI1pF//c7Cck=; b=lHfnRYfgioVGODqGLcejuedOvsKYqh3kqLu3KTc8OgHhTaMsXIzzE/0Qcg9Af7TP7I 99o7fGe2b03kEMnuTvB9bXj85EhcoKrXqknsTrKZchFd2NpWkSRW2RZeAnz1aW7G0PX0 /WEP8bZsJeNNR9vrsPASjLBjPBpST0gzCLqther+E0Po1Gruqj1sAZlC2Mad0DKHB+8X LuI5++Yv52fSXC9ObFTiT3RMxIG/A0RWyAiAGzlOhq8FHwEXSrW3ksVV3KD8gMAe+idy UEGWwYzs8S3hZjIapoufAQjpBUHinFJEg2njeQ2yiuldtTPbDa2sWRaJgfZMNdy7mR6M 4Zfg== X-Gm-Message-State: AOPr4FX/DooW/7b6+bm99W7jKeLK1izpw4Rf23GOH60/FffnANfiGjKFKlnLxxslYV9jOw== X-Received: by 10.194.82.168 with SMTP id j8mr37994183wjy.37.1461573532952; Mon, 25 Apr 2016 01:38:52 -0700 (PDT) Received: from [192.168.0.9] (bcde049e.skybroadband.com. [188.222.4.158]) by smtp.gmail.com with ESMTPSA id ki9sm22438356wjb.37.2016.04.25.01.38.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 01:38:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lars Kurth In-Reply-To: <571DE6AC02000078000E5238@prv-mh.provo.novell.com> Date: Mon, 25 Apr 2016 09:38:50 +0100 Message-Id: <3FEFAB8B-E9FA-4B7E-9767-B2FBB11BC88B@gmail.com> References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> <571DE6AC02000078000E5238@prv-mh.provo.novell.com> To: Jan Beulich X-Mailer: Apple Mail (2.2104) Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , appointments@xenproject.org, publicity@lists.xenproject.org, George Dunlap , Zibby Keaton Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" Cj4gT24gMjUgQXByIDIwMTYsIGF0IDA4OjQzLCBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5j b20+IHdyb3RlOgo+IAo+Pj4+IE9uIDIyLjA0LjE2IGF0IDIwOjQ5LCA8bGFycy5rdXJ0aC54ZW5A Z21haWwuY29tPiB3cm90ZToKPj4gQ29tbWl0dGVycwo+PiAKPj4gVGhlIGZvbGxvd2luZyBwZW9w bGUgaGF2ZSBiZWVuIGVsZWN0ZWQgdG8gYmUgbmV3IENvbW1pdHRlcnMgdG8gdGhlIHByb2plY3Qs IAo+PiBhbG9uZ3NpZGUgSWFuIENhbXBiZWxsLCBJYW4gSmFja3NvbiwgSmFuIEJldWxpY2ggYW5k IEtvbnJhZCBSemVzenV0ZWsgV2lsazoKPj4gCj4+IEFuZHJldyBDb29wZXIgaGFzIGJlZW4gd29y a2luZyBvbiB0aGUgSHlwZXJ2aXNvciBzaW5jZSAyMDExIGFuZCBoYXMgYWRkZWQgYSAKPj4gbnVt YmVyIG9mIG1ham9yIG5ldyBmZWF0dXJlcyBzdWNoIGFzIE1pZ3JhdGlvbiB2Miwgc2lnbmlmaWNh bnQgY2hhbmdlIHRvIHRyYXAgCj4+IGhhbmRsaW5nLCBpbXByb3ZlbWVudHMgdG8gY3B1aWQgaGFu ZGxpbmcgZm9yIGd1ZXN0cyBhbmQgbWFueSBtb3JlLgo+PiAKPj4gR2VvcmdlIER1bmxhcCBoYXMg YmVlbiB3b3JraW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMDggYW5kIHdhcyBoZWF2aWx5 IAo+PiBpbnZvbHZlZCBpbiBtYWtpbmcgdGhlIHRyYWNpbmcgc3lzdGVtIHVzZWFibGUgZm9yCj4+ IHBlcmZvcm1hbmNlIGFuYWx5c2lzLCBvcHRpbWlzaW5nIHRoZSBzaGFkb3cgY29kZSwgd3JvdGUg dGhlIGNyZWRpdDIgCj4+IHNjaGVkdWxlciBhbmQgZGV2ZWxvcGVkIG1hbnkgb3RoZXIgc2lnbmlm aWNhbnQgZmVhdHVyZXMgYW5kIGltcHJvdmVtZW50cyBpbiAKPj4gdGhlIGh5cGVydmlzb3IuIElu IGFkZGl0aW9uLCBoZSB3YXMgb3VyIGZpcnN0IFJlbGVhc2UgTWFuYWdlciBhbmQgaXMgbGVhZGlu ZyAKPj4gdGhlIENlbnRPUyBWaXJ0dWFsaXNhdGlvbiBTSUcgd2l0aGluIENlbnRPUy4KPiAKPiBT aG91bGRuJ3QgeW91LCBqdXN0IGxpa2UgeW91IGRvIGZvciBXZWksIG1lbnRpb24gR2VvcmdlJ3Mg cm9sZSBhcwo+IHJlbGVhc2UgbWFuYWdlciAoSSBhZG1pdCBJIGRvbid0IHJlY2FsbCBmb3Igd2hp Y2ggdmVyc2lvbihzKSB0aGlzIHdhcyk/CgpJIHRob3VnaHQgSSBtZW50aW9uZWQgaXQuIElkZWFs bHksIGVhY2ggbmV3IGNvbW1pdHRlciB3b3VsZCBoaWdobGlnaHQgdGhlIHRoaW5ncyB0aGF0IHRo ZXkgdGhpbmsgc2hvdWxkIGJlIGhpZ2hsaWdodGVkLiAgCgpXZSBoYXZlIGEgYml0IG1vcmUgdGlt ZSBub3csIGlmIHdlIHdhaXQgdGlsbCBuZXh0IE1vbmRheSwgYXMgU2FyYWggc3VnZ2VzdGVkLgoK Pj4gU2VjdXJpdHkgVGVhbQo+PiAKPj4gSW4gYWRkaXRpb24sIEFuZHJldyBDb29wZXIgYW5kIEdl b3JnZSBEdW5sYXAgYXJlIG5vdyBhbHNvIG1lbWJlcnMgb2YgdGhlIFhlbiAKPj4gUHJvamVjdCBT ZWN1cml0eSBUZWFtLCBhbG9uZ3NpZGUgSWFuIEphY2tzb24sIEphbiBCZXVsaWNoIGFuZCBUaW0g RGVlZ2FuLgo+IAo+IC4uLiBhbmQgS29ucmFkLgoKQXBvbG9naWVzLCBJIG1pc3NlZCBoaW0uCgpJ IHdvbmRlciB3aGV0aGVyIHdlIHNob3VsZCBhbHNvIG1lbnRpb24gb3VyIFFFTVUgYW5kIEJTRCBj b21taXR0ZXJzLCBidXQgYXMgZmFyIGFzIEkgcmVjYWxsIHRoZXJlIHdlcmUgbm8gY2hhbmdlcy4K CkxhcnMKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K UHVibGljaXR5IG1haWxpbmcgbGlzdApQdWJsaWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0 cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNp dHkK From publicity-bounces@lists.xenproject.org Mon Apr 25 09:57:49 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 Apr 2016 09:57:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1audH2-0002Yo-GD; Mon, 25 Apr 2016 09:57:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1audH0-0002Yh-NT for publicity@lists.xenproject.org; Mon, 25 Apr 2016 09:57:46 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id A8/C8-02960-91AED175; Mon, 25 Apr 2016 09:57:45 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRWlGSWpSXmKPExsXitHSDva7kK9l wg+Odcha/+9YyOjB6HP5whSWAMYo1My8pvyKBNeNpwyvmgtm8FVd+/mNvYPzM1cXIySEh4C+x 7/YrRhBbWCBZYs7dh2C2iICXxMkD01i6GLk4hASuMEqc/DOLEcRhFljKJPGu5RkTSBWbgJ7Ev ONfWUBsXgFNiQOLt4HFWQRUJfqnLQazRQWiJf4sb2WFqBGUODnzCVg9p4CtxLeXK8FqmAUMJI 4smsMKYctLNG+dzQxiCwHNWfzgKDvEpdwSt09PZZ7AyD8LyahZSNpnIWlfwMi8ilGjOLWoLLV I19BYL6koMz2jJDcxM0fX0NBELze1uDgxPTUnMalYLzk/dxMjMBDrGRgYdzDu2u55iFGSg0lJ lPfkIdlwIb6k/JTKjMTijPii0pzU4kOMMhwcShK8i18A5QSLUtNTK9Iyc4AxAZOW4OBREuFdD 5LmLS5IzC3OTIdInWJUlBLnPQ2SEABJZJTmwbXB4vASo6yUMC8jAwODEE9BalFuZgmq/CtGcQ 5GJWHeJpApPJl5JXDTXwEtZgJafPkQ2OKSRISUVANjjX1ZQvv6e2Z8B2v1/nd6/3Rkd7Vr/HP VrNc3/uLXOMnzdhHvP0yf4r/u8v5Y9VJHuwnSikvPcEmc0Ljc5LY8/PoCi00/99+avO2pSsjP oNdrHtxr1u61j/x9+MQtge83GMxzv+S4Te8u/hk9U/fvzU3F2zYcsnCe+FUk8HjxJ5uHpnHMk 7onKLEUZyQaajEXFScCAE8Q+Fi+AgAA X-Env-Sender: prvs=916053e51=George.Dunlap@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1461578263!37247043!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: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 54310 invoked from network); 25 Apr 2016 09:57:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 25 Apr 2016 09:57:45 -0000 X-IronPort-AV: E=Sophos;i="5.24,532,1454976000"; d="scan'208";a="356173230" To: Lars Kurth , Jan Beulich References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> <571DE6AC02000078000E5238@prv-mh.provo.novell.com> <3FEFAB8B-E9FA-4B7E-9767-B2FBB11BC88B@gmail.com> From: George Dunlap Message-ID: <571DEA15.5080003@citrix.com> Date: Mon, 25 Apr 2016 10:57:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <3FEFAB8B-E9FA-4B7E-9767-B2FBB11BC88B@gmail.com> X-DLP: MIA2 Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , appointments@xenproject.org, publicity@lists.xenproject.org, Zibby Keaton Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" T24gMjUvMDQvMTYgMDk6MzgsIExhcnMgS3VydGggd3JvdGU6Cj4gCj4+IE9uIDI1IEFwciAyMDE2 LCBhdCAwODo0MywgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPiB3cm90ZToKPj4KPj4+ Pj4gT24gMjIuMDQuMTYgYXQgMjA6NDksIDxsYXJzLmt1cnRoLnhlbkBnbWFpbC5jb20+IHdyb3Rl Ogo+Pj4gQ29tbWl0dGVycwo+Pj4KPj4+IFRoZSBmb2xsb3dpbmcgcGVvcGxlIGhhdmUgYmVlbiBl bGVjdGVkIHRvIGJlIG5ldyBDb21taXR0ZXJzIHRvIHRoZSBwcm9qZWN0LCAKPj4+IGFsb25nc2lk ZSBJYW4gQ2FtcGJlbGwsIElhbiBKYWNrc29uLCBKYW4gQmV1bGljaCBhbmQgS29ucmFkIFJ6ZXN6 dXRlayBXaWxrOgo+Pj4KPj4+IEFuZHJldyBDb29wZXIgaGFzIGJlZW4gd29ya2luZyBvbiB0aGUg SHlwZXJ2aXNvciBzaW5jZSAyMDExIGFuZCBoYXMgYWRkZWQgYSAKPj4+IG51bWJlciBvZiBtYWpv ciBuZXcgZmVhdHVyZXMgc3VjaCBhcyBNaWdyYXRpb24gdjIsIHNpZ25pZmljYW50IGNoYW5nZSB0 byB0cmFwIAo+Pj4gaGFuZGxpbmcsIGltcHJvdmVtZW50cyB0byBjcHVpZCBoYW5kbGluZyBmb3Ig Z3Vlc3RzIGFuZCBtYW55IG1vcmUuCj4+Pgo+Pj4gR2VvcmdlIER1bmxhcCBoYXMgYmVlbiB3b3Jr aW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMDggYW5kIHdhcyBoZWF2aWx5IAo+Pj4gaW52 b2x2ZWQgaW4gbWFraW5nIHRoZSB0cmFjaW5nIHN5c3RlbSB1c2VhYmxlIGZvcgo+Pj4gcGVyZm9y bWFuY2UgYW5hbHlzaXMsIG9wdGltaXNpbmcgdGhlIHNoYWRvdyBjb2RlLCB3cm90ZSB0aGUgY3Jl ZGl0MiAKPj4+IHNjaGVkdWxlciBhbmQgZGV2ZWxvcGVkIG1hbnkgb3RoZXIgc2lnbmlmaWNhbnQg ZmVhdHVyZXMgYW5kIGltcHJvdmVtZW50cyBpbiAKPj4+IHRoZSBoeXBlcnZpc29yLiBJbiBhZGRp dGlvbiwgaGUgd2FzIG91ciBmaXJzdCBSZWxlYXNlIE1hbmFnZXIgYW5kIGlzIGxlYWRpbmcgCj4+ PiB0aGUgQ2VudE9TIFZpcnR1YWxpc2F0aW9uIFNJRyB3aXRoaW4gQ2VudE9TLgo+Pgo+PiBTaG91 bGRuJ3QgeW91LCBqdXN0IGxpa2UgeW91IGRvIGZvciBXZWksIG1lbnRpb24gR2VvcmdlJ3Mgcm9s ZSBhcwo+PiByZWxlYXNlIG1hbmFnZXIgKEkgYWRtaXQgSSBkb24ndCByZWNhbGwgZm9yIHdoaWNo IHZlcnNpb24ocykgdGhpcyB3YXMpPwo+IAo+IEkgdGhvdWdodCBJIG1lbnRpb25lZCBpdC4KCldl bGwgSSBzZWUgIlJlbGVhc2UgTWFuYWdlciIgaW4gY2FwaXRhbHMgaW4gdGhlIHNlY29uZC10by1s YXN0IGxpbmUgb2YKdGhlIHF1b3RlIEphbiByZXNwb25kcyB0byBoZXJlLCBzbyBJIHRoaW5rIHlv dSByZW1lbWJlciBjb3JyZWN0bHkuIDotKQpJIHRoaW5rIEkgZGlkIHRoZSByZWxlYXNlIG1hbmFn ZW1lbnQgZm9yIDQuMyBhbmQgNC40LCByaWdodD8KCkkndmUgYWN0dWFsbHkgYmVlbiBpbnZvbHZl ZCBpbiB0aGUgaHlwZXJ2aXNvciBzaW5jZSAyMDA1LiA6LSkgIChJbiBmYWN0LAppdCByYXRoZXIg bG9va3MgbGlrZSBJIHNpZ25lZCB1cCBmb3IgZ21haWwgc3BlY2lmaWNhbGx5IHRvIGhhbmRsZSB0 aGUKeGVuLWRldmVsIHRyYWZmaWMhKQoKSSdkIHByb2JhYmx5IGFkZCB0aGF0IEknbSBjdXJyZW50 bHkgbWFpbnRhaW5lciBmb3IgdGhlIHg4NiBtbSBzdWJzeXN0ZW0KYW5kIGNvLW1haW50YWluZXIg Zm9yIHRoZSBzY2hlZHVsZXIgYXMgd2VsbC4KCiAtR2VvcmdlCgoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5IG1haWxpbmcgbGlzdApQdWJs aWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2Nn aS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK From publicity-bounces@lists.xenproject.org Mon Apr 25 09:57:49 2016 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 Apr 2016 09:57:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1audH2-0002Yo-GD; Mon, 25 Apr 2016 09:57:48 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1audH0-0002Yh-NT for publicity@lists.xenproject.org; Mon, 25 Apr 2016 09:57:46 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id A8/C8-02960-91AED175; Mon, 25 Apr 2016 09:57:45 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRWlGSWpSXmKPExsXitHSDva7kK9l wg+Odcha/+9YyOjB6HP5whSWAMYo1My8pvyKBNeNpwyvmgtm8FVd+/mNvYPzM1cXIySEh4C+x 7/YrRhBbWCBZYs7dh2C2iICXxMkD01i6GLk4hASuMEqc/DOLEcRhFljKJPGu5RkTSBWbgJ7Ev ONfWUBsXgFNiQOLt4HFWQRUJfqnLQazRQWiJf4sb2WFqBGUODnzCVg9p4CtxLeXK8FqmAUMJI 4smsMKYctLNG+dzQxiCwHNWfzgKDvEpdwSt09PZZ7AyD8LyahZSNpnIWlfwMi8ilGjOLWoLLV I19BYL6koMz2jJDcxM0fX0NBELze1uDgxPTUnMalYLzk/dxMjMBDrGRgYdzDu2u55iFGSg0lJ lPfkIdlwIb6k/JTKjMTijPii0pzU4kOMMhwcShK8i18A5QSLUtNTK9Iyc4AxAZOW4OBREuFdD 5LmLS5IzC3OTIdInWJUlBLnPQ2SEABJZJTmwbXB4vASo6yUMC8jAwODEE9BalFuZgmq/CtGcQ 5GJWHeJpApPJl5JXDTXwEtZgJafPkQ2OKSRISUVANjjX1ZQvv6e2Z8B2v1/nd6/3Rkd7Vr/HP VrNc3/uLXOMnzdhHvP0yf4r/u8v5Y9VJHuwnSikvPcEmc0Ljc5LY8/PoCi00/99+avO2pSsjP oNdrHtxr1u61j/x9+MQtge83GMxzv+S4Te8u/hk9U/fvzU3F2zYcsnCe+FUk8HjxJ5uHpnHMk 7onKLEUZyQaajEXFScCAE8Q+Fi+AgAA X-Env-Sender: prvs=916053e51=George.Dunlap@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1461578263!37247043!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: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 54310 invoked from network); 25 Apr 2016 09:57:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 25 Apr 2016 09:57:45 -0000 X-IronPort-AV: E=Sophos;i="5.24,532,1454976000"; d="scan'208";a="356173230" To: Lars Kurth , Jan Beulich References: <5F410C62-7B22-4750-A107-F454772EBC4E@gmail.com> <571DE6AC02000078000E5238@prv-mh.provo.novell.com> <3FEFAB8B-E9FA-4B7E-9767-B2FBB11BC88B@gmail.com> From: George Dunlap Message-ID: <571DEA15.5080003@citrix.com> Date: Mon, 25 Apr 2016 10:57:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <3FEFAB8B-E9FA-4B7E-9767-B2FBB11BC88B@gmail.com> X-DLP: MIA2 Cc: Juergen Gross , sstabellini@kernel.org, Andrew Cooper , appointments@xenproject.org, publicity@lists.xenproject.org, Zibby Keaton Subject: Re: [Publicity] [For review] Please Welcome new Members of the Xen Project Hypervisor Leadership Team X-BeenThere: publicity@lists.xenproject.org X-Mailman-Version: 2.1.18 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 Errors-To: publicity-bounces@lists.xenproject.org Sender: "Publicity" T24gMjUvMDQvMTYgMDk6MzgsIExhcnMgS3VydGggd3JvdGU6Cj4gCj4+IE9uIDI1IEFwciAyMDE2 LCBhdCAwODo0MywgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPiB3cm90ZToKPj4KPj4+ Pj4gT24gMjIuMDQuMTYgYXQgMjA6NDksIDxsYXJzLmt1cnRoLnhlbkBnbWFpbC5jb20+IHdyb3Rl Ogo+Pj4gQ29tbWl0dGVycwo+Pj4KPj4+IFRoZSBmb2xsb3dpbmcgcGVvcGxlIGhhdmUgYmVlbiBl bGVjdGVkIHRvIGJlIG5ldyBDb21taXR0ZXJzIHRvIHRoZSBwcm9qZWN0LCAKPj4+IGFsb25nc2lk ZSBJYW4gQ2FtcGJlbGwsIElhbiBKYWNrc29uLCBKYW4gQmV1bGljaCBhbmQgS29ucmFkIFJ6ZXN6 dXRlayBXaWxrOgo+Pj4KPj4+IEFuZHJldyBDb29wZXIgaGFzIGJlZW4gd29ya2luZyBvbiB0aGUg SHlwZXJ2aXNvciBzaW5jZSAyMDExIGFuZCBoYXMgYWRkZWQgYSAKPj4+IG51bWJlciBvZiBtYWpv ciBuZXcgZmVhdHVyZXMgc3VjaCBhcyBNaWdyYXRpb24gdjIsIHNpZ25pZmljYW50IGNoYW5nZSB0 byB0cmFwIAo+Pj4gaGFuZGxpbmcsIGltcHJvdmVtZW50cyB0byBjcHVpZCBoYW5kbGluZyBmb3Ig Z3Vlc3RzIGFuZCBtYW55IG1vcmUuCj4+Pgo+Pj4gR2VvcmdlIER1bmxhcCBoYXMgYmVlbiB3b3Jr aW5nIG9uIHRoZSBIeXBlcnZpc29yIHNpbmNlIDIwMDggYW5kIHdhcyBoZWF2aWx5IAo+Pj4gaW52 b2x2ZWQgaW4gbWFraW5nIHRoZSB0cmFjaW5nIHN5c3RlbSB1c2VhYmxlIGZvcgo+Pj4gcGVyZm9y bWFuY2UgYW5hbHlzaXMsIG9wdGltaXNpbmcgdGhlIHNoYWRvdyBjb2RlLCB3cm90ZSB0aGUgY3Jl ZGl0MiAKPj4+IHNjaGVkdWxlciBhbmQgZGV2ZWxvcGVkIG1hbnkgb3RoZXIgc2lnbmlmaWNhbnQg ZmVhdHVyZXMgYW5kIGltcHJvdmVtZW50cyBpbiAKPj4+IHRoZSBoeXBlcnZpc29yLiBJbiBhZGRp dGlvbiwgaGUgd2FzIG91ciBmaXJzdCBSZWxlYXNlIE1hbmFnZXIgYW5kIGlzIGxlYWRpbmcgCj4+ PiB0aGUgQ2VudE9TIFZpcnR1YWxpc2F0aW9uIFNJRyB3aXRoaW4gQ2VudE9TLgo+Pgo+PiBTaG91 bGRuJ3QgeW91LCBqdXN0IGxpa2UgeW91IGRvIGZvciBXZWksIG1lbnRpb24gR2VvcmdlJ3Mgcm9s ZSBhcwo+PiByZWxlYXNlIG1hbmFnZXIgKEkgYWRtaXQgSSBkb24ndCByZWNhbGwgZm9yIHdoaWNo IHZlcnNpb24ocykgdGhpcyB3YXMpPwo+IAo+IEkgdGhvdWdodCBJIG1lbnRpb25lZCBpdC4KCldl bGwgSSBzZWUgIlJlbGVhc2UgTWFuYWdlciIgaW4gY2FwaXRhbHMgaW4gdGhlIHNlY29uZC10by1s YXN0IGxpbmUgb2YKdGhlIHF1b3RlIEphbiByZXNwb25kcyB0byBoZXJlLCBzbyBJIHRoaW5rIHlv dSByZW1lbWJlciBjb3JyZWN0bHkuIDotKQpJIHRoaW5rIEkgZGlkIHRoZSByZWxlYXNlIG1hbmFn ZW1lbnQgZm9yIDQuMyBhbmQgNC40LCByaWdodD8KCkkndmUgYWN0dWFsbHkgYmVlbiBpbnZvbHZl ZCBpbiB0aGUgaHlwZXJ2aXNvciBzaW5jZSAyMDA1LiA6LSkgIChJbiBmYWN0LAppdCByYXRoZXIg bG9va3MgbGlrZSBJIHNpZ25lZCB1cCBmb3IgZ21haWwgc3BlY2lmaWNhbGx5IHRvIGhhbmRsZSB0 aGUKeGVuLWRldmVsIHRyYWZmaWMhKQoKSSdkIHByb2JhYmx5IGFkZCB0aGF0IEknbSBjdXJyZW50 bHkgbWFpbnRhaW5lciBmb3IgdGhlIHg4NiBtbSBzdWJzeXN0ZW0KYW5kIGNvLW1haW50YWluZXIg Zm9yIHRoZSBzY2hlZHVsZXIgYXMgd2VsbC4KCiAtR2VvcmdlCgoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUHVibGljaXR5IG1haWxpbmcgbGlzdApQdWJs aWNpdHlAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cDovL2xpc3RzLnhlbnByb2plY3Qub3JnL2Nn aS1iaW4vbWFpbG1hbi9saXN0aW5mby9wdWJsaWNpdHkK