From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roddy Rodstein Subject: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Wed, 09 Oct 2013 11:24:22 -0700 Message-ID: <52559F56.3070901@mokumsolutions.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080407050902060300040107" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VTyQr-0001dg-Ci for xen-devel@lists.xenproject.org; Wed, 09 Oct 2013 18:24:25 +0000 Received: by mail-pb0-f54.google.com with SMTP id ro12so1300633pbb.13 for ; Wed, 09 Oct 2013 11:24:20 -0700 (PDT) List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------080407050902060300040107 Content-Type: multipart/alternative; boundary="------------060708070603030902080608" --------------060708070603030902080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings, Thank you in advance for your support! Our HP Xen 4.1.3 servers have 1TB of RAM, each Xen servers take 20 minutes to boot largely due to the "scrub free RAM" phase. If/when we have dom0 failures and HA kicks-in, we would like to reduce the boot time to make the resource quickly available, perhaps using the no-bootscrub attribute in grub.conf. Could you please share your comments about turning of RAM scrubbing, i.e. have you seen any consequences, security issues and/or threats, red flags, etc...? We have asked the same question at the commercially supported Xen forums, i.e. Oracle and Citrix, as well as to each aforementioned support team, and have not received a lick of meaningful information. Respectfully, Roddy -- Roddy Rodstein CEO and Founder Mokum Solutions, Inc. Phone: (415) 252-9164 E-mail: roddy.rodstein@mokumsolutions.com Web: http://mokumsolutions.com and http://itnewscast.com Follow me on Twitter: http://twitter.com/itnewscast Up-to-date Oracle news by Mokum: http://itnewscast.com/ CONFIDENTIAL "The information contained in this e-mail and any attachment is confidential. It is intended only for the named addressee(s). If you are not the named addressee please notify the sender immediately and do not disclose, copy or distribute the contents to any other person other than the intended addressee(s)" --------------060708070603030902080608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Greetings,

Thank you in advance for your support!

Our HP Xen 4.1.3 servers have 1TB of RAM, each Xen servers take 20 minutes to boot largely due to the "scrub free RAM" phase. If/when we have dom0 failures and HA kicks-in, we would like to reduce the boot time to make the resource quickly available, perhaps using the no-bootscrub attribute in grub.conf.

Could you please share your comments about turning of RAM scrubbing, i.e. have you seen any consequences, security issues and/or threats, red flags, etc...?

We have asked the same question at the commercially supported Xen forums, i.e. Oracle and Citrix, as well as to each aforementioned support team, and have not received a lick of meaningful information.

Respectfully,

Roddy

-- 
Roddy Rodstein  CEO and Founder
Mokum Solutions, Inc.
Phone:  (415) 252-9164
E-mail: roddy.rodstein@mokumsolutions.com  Web: http://mokumsolutions.com and http://itnewscast.com
Follow me on Twitter: http://twitter.com/itnewscast
Up-to-date Oracle news by Mokum: http://itnewscast.com/
CONFIDENTIAL  "The information contained in this e-mail and any attachment is confidential. It is intended only for the named addressee(s). If you are not the named addressee please notify the sender immediately and do not disclose, copy or distribute the contents to any other person other than the intended addressee(s)"

--------------060708070603030902080608-- --------------080407050902060300040107 Content-Type: text/x-vcard; charset=utf-8; name="roddy_rodstein.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="roddy_rodstein.vcf" begin:vcard fn:Roddy Rodstein n:Rodstein;Roddy email;internet:roddy.rodstein@mokumsolutions.com tel;work:4152529164 tel;cell:4158602851 version:2.1 end:vcard --------------080407050902060300040107 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------080407050902060300040107-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Thu, 10 Oct 2013 09:27:03 +0300 Message-ID: <20131010062703.GG2924@reaktio.net> References: <52559F56.3070901@mokumsolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VU9iD-0005Xk-Lk for xen-devel@lists.xenproject.org; Thu, 10 Oct 2013 06:27:05 +0000 Content-Disposition: inline In-Reply-To: <52559F56.3070901@mokumsolutions.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roddy Rodstein Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Wed, Oct 09, 2013 at 11:24:22AM -0700, Roddy Rodstein wrote: > Greetings, > > Thank you in advance for your support! > > Our HP Xen 4.1.3 servers have 1TB of RAM, each Xen servers take 20 minutes > to boot largely due to the "scrub free RAM" phase. If/when we have dom0 > failures and HA kicks-in, we would like to reduce the boot time to make > the resource quickly available, perhaps using the no-bootscrub attribute > in grub.conf. > > Could you please share your comments about turning of RAM scrubbing, i.e. > have you seen any consequences, security issues and/or threats, red flags, > etc...? > > We have asked the same question at the commercially supported Xen forums, > i.e. Oracle and Citrix, as well as to each aforementioned support team, > and have not received a lick of meaningful information. > If that's a custom build of Xen you can apply the patches that optimize the boot time memory scrubbing, they've been posted to xen-devel a couple of times.. -- Pasi > > > Respectfully, > > Roddy > > -- > Roddy Rodstein CEO and Founder > Mokum Solutions, Inc. > Phone: (415) 252-9164 > E-mail: [1]roddy.rodstein@mokumsolutions.com Web: [2]http://mokumsolutions.com and [3]http://itnewscast.com > Follow me on Twitter: [4]http://twitter.com/itnewscast > Up-to-date Oracle news by Mokum: [5]http://itnewscast.com/ > CONFIDENTIAL "The information contained in this e-mail and any attachment is confidential. It is intended only for the named addressee(s). If you are not the named addressee please notify the sender immediately and do not disclose, copy or distribute the contents to any other person other than the intended addressee(s)" > > References > > Visible links > 1. mailto:roddy.rodstein@mokumsolutions.com > 2. http://mokumsolutions.com/ > 3. http://itnewscast.com/ > 4. http://twitter.com/itnewscast > 5. http://itnewscast.com/ > begin:vcard > fn:Roddy Rodstein > n:Rodstein;Roddy > email;internet:roddy.rodstein@mokumsolutions.com > tel;work:4152529164 > tel;cell:4158602851 > version:2.1 > end:vcard > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Rowe Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Thu, 10 Oct 2013 09:39:21 +0100 Message-ID: <525667B9.9010309@eu.citrix.com> References: <52559F56.3070901@mokumsolutions.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5803152893617839745==" Return-path: In-Reply-To: <52559F56.3070901@mokumsolutions.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org, roddy.rodstein@mokumsolutions.com List-Id: xen-devel@lists.xenproject.org --===============5803152893617839745== Content-Type: multipart/alternative; boundary="------------010800070304000300040806" --------------010800070304000300040806 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 09/10/13 19:24, Roddy Rodstein wrote: > > Greetings, > > Thank you in advance for your support! > > Our HP Xen 4.1.3 servers have 1TB of RAM, each Xen servers take 20 > minutes to boot largely due to the "scrub free RAM" phase. If/when we > have dom0 failures and HA kicks-in, we would like to reduce the boot > time to make the resource quickly available, perhaps using the > no-bootscrub attribute in grub.conf. > > Malcolm's patch to parallelize scrubbing was posted recently http://lists.xen.org/archives/html/xen-devel/2013-09/msg03171.html I don't think it's been committed to xen-unstable yet, Simon --------------010800070304000300040806 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

On 09/10/13 19:24, Roddy Rodstein wrote:

Greetings,

Thank you in advance for your support!

Our HP Xen 4.1.3 servers have 1TB of RAM, each Xen servers take 20 minutes to boot largely due to the "scrub free RAM" phase. If/when we have dom0 failures and HA kicks-in, we would like to reduce the boot time to make the resource quickly available, perhaps using the no-bootscrub attribute in grub.conf.

Malcolm's patch to parallelize scrubbing was posted recently

http://lists.xen.org/archives/html/xen-devel/2013-09/msg03171.html

I don't think it's been committed to xen-unstable yet,

Simon

--------------010800070304000300040806-- --===============5803152893617839745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5803152893617839745==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Thu, 10 Oct 2013 09:47:43 +0100 Message-ID: <1381394863.7600.44.camel@kazak.uk.xensource.com> References: <52559F56.3070901@mokumsolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VUBuP-0007LZ-2S for xen-devel@lists.xenproject.org; Thu, 10 Oct 2013 08:47:49 +0000 In-Reply-To: <52559F56.3070901@mokumsolutions.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roddy Rodstein Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Wed, 2013-10-09 at 11:24 -0700, Roddy Rodstein wrote: > Could you please share your comments about turning of RAM scrubbing, > i.e. have you seen any consequences, security issues and/or threats, > red flags, etc...? The scrub is there to protect against possibly stale data in RAM left over from guests running during the previous boot being exposed to new guests. If you don't care about that threat then you don't need to scan the boot RAM. Ian. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Thu, 10 Oct 2013 10:42:14 +0100 Message-ID: <52567676.3010102@citrix.com> References: <52559F56.3070901@mokumsolutions.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4164725848202587727==" Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VUClT-0008R9-El for xen-devel@lists.xenproject.org; Thu, 10 Oct 2013 09:42:39 +0000 In-Reply-To: <52559F56.3070901@mokumsolutions.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roddy Rodstein Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============4164725848202587727== Content-Type: multipart/alternative; boundary="------------050007000604080901050502" --------------050007000604080901050502 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 09/10/13 19:24, Roddy Rodstein wrote: > > Greetings, > > > > Thank you in advance for your support! > > > > Our HP Xen 4.1.3 servers have 1TB of RAM, each Xen servers take 20 > minutes to boot largely due to the "scrub free RAM" phase. If/when we > have dom0 failures and HA kicks-in, we would like to reduce the boot > time to make the resource quickly available, perhaps using the > no-bootscrub attribute in grub.conf. > > > > Could you please share your comments about turning of RAM scrubbing, > i.e. have you seen any consequences, security issues and/or threats, > red flags, etc...? > > > > We have asked the same question at the commercially supported Xen > forums, i.e. Oracle and Citrix, as well as to each aforementioned > support team, and have not received a lick of meaningful information. > > > > Respectfully, > > Roddy > In the Xen model, domains are responsible for clearing any sensitive data they have out of memory before shutdown. The bootscrub is a preventative measure to ensure that after a crash, stale domain information is cleared from RAM before that RAM is reused for a new VM. If this is not a concern for you, then you can easily turn bootscrub off by adding "no-bootscrub" to the Xen command line. ~Andrew --------------050007000604080901050502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

On 09/10/13 19:24, Roddy Rodstein wrote:

Greetings,

Thank you in advance for your support!

Our HP Xen 4.1.3 servers have 1TB of RAM, each Xen servers take 20 minutes to boot largely due to the "scrub free RAM" phase. If/when we have dom0 failures and HA kicks-in, we would like to reduce the boot time to make the resource quickly available, perhaps using the no-bootscrub attribute in grub.conf.

Could you please share your comments about turning of RAM scrubbing, i.e. have you seen any consequences, security issues and/or threats, red flags, etc...?

We have asked the same question at the commercially supported Xen forums, i.e. Oracle and Citrix, as well as to each aforementioned support team, and have not received a lick of meaningful information.

Respectfully,

Roddy

In the Xen model, domains are responsible for clearing any sensitive data they have out of memory before shutdown.

The bootscrub is a preventative measure to ensure that after a crash, stale domain information is cleared from RAM before that RAM is reused for a new VM.

If this is not a concern for you, then you can easily turn bootscrub off by adding "no-bootscrub" to the Xen command line.

~Andrew
--------------050007000604080901050502-- --===============4164725848202587727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4164725848202587727==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Wilson Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Sun, 10 Nov 2013 14:25:11 -0800 Message-ID: <20131110222511.GA22949@u109add4315675089e695.ant.amazon.com> References: <52559F56.3070901@mokumsolutions.com> <52567676.3010102@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VfdRY-0002nZ-79 for xen-devel@lists.xenproject.org; Sun, 10 Nov 2013 22:25:20 +0000 Received: by mail-pb0-f43.google.com with SMTP id md4so4377139pbc.2 for ; Sun, 10 Nov 2013 14:25:16 -0800 (PST) Content-Disposition: inline In-Reply-To: <52567676.3010102@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, Roddy Rodstein List-Id: xen-devel@lists.xenproject.org On Thu, Oct 10, 2013 at 10:42:14AM +0100, Andrew Cooper wrote: > On 09/10/13 19:24, Roddy Rodstein wrote: [...] > > Could you please share your comments about turning of RAM scrubbing, > > i.e. have you seen any consequences, security issues and/or threats, > > red flags, etc...? [...] > In the Xen model, domains are responsible for clearing any sensitive > data they have out of memory before shutdown. This isn't strictly true. Memory is scrubbed by Xen when the domain cannot do it for itself (i.e., when a domain is dying during shutdown). However by default domains /are/ responsible for scrubbing pages that are returned to Xen via a reservation adjustment (i.e., pages returned via the balloon driver). --msw > The bootscrub is a preventative measure to ensure that after a crash, > stale domain information is cleared from RAM before that RAM is reused > for a new VM. > > If this is not a concern for you, then you can easily turn bootscrub off > by adding "no-bootscrub" to the Xen command line. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Mon, 11 Nov 2013 10:14:35 +0000 Message-ID: <1384164875.3189.179.camel@kazak.uk.xensource.com> References: <52559F56.3070901@mokumsolutions.com> <52567676.3010102@citrix.com> <20131110222511.GA22949@u109add4315675089e695.ant.amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VfoX0-0001A4-8b for xen-devel@lists.xenproject.org; Mon, 11 Nov 2013 10:15:42 +0000 In-Reply-To: <20131110222511.GA22949@u109add4315675089e695.ant.amazon.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Matt Wilson Cc: Andrew Cooper , Roddy Rodstein , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Sun, 2013-11-10 at 14:25 -0800, Matt Wilson wrote: > On Thu, Oct 10, 2013 at 10:42:14AM +0100, Andrew Cooper wrote: > > On 09/10/13 19:24, Roddy Rodstein wrote: > > [...] > > > > Could you please share your comments about turning of RAM scrubbing, > > > i.e. have you seen any consequences, security issues and/or threats, > > > red flags, etc...? > > [...] > > > In the Xen model, domains are responsible for clearing any sensitive > > data they have out of memory before shutdown. > > This isn't strictly true. Memory is scrubbed by Xen when the domain > cannot do it for itself (i.e., when a domain is dying during > shutdown). Isn't this only when the domain is killed by the toolstack or crashes etc. On a graceful shutdown I thought the guest was still responsible for clearing any memory it cared about. > However by default domains /are/ responsible for scrubbing > pages that are returned to Xen via a reservation adjustment (i.e., > pages returned via the balloon driver). > > --msw > > > The bootscrub is a preventative measure to ensure that after a crash, > > stale domain information is cleared from RAM before that RAM is reused > > for a new VM. > > > > If this is not a concern for you, then you can easily turn bootscrub off > > by adding "no-bootscrub" to the Xen command line. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Mon, 11 Nov 2013 10:33:07 +0000 Message-ID: <5280C0730200007800101B69@nat28.tlf.novell.com> References: <52559F56.3070901@mokumsolutions.com> <52567676.3010102@citrix.com> <20131110222511.GA22949@u109add4315675089e695.ant.amazon.com> <1384164875.3189.179.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vfonw-0002cf-NT for xen-devel@lists.xenproject.org; Mon, 11 Nov 2013 10:33:12 +0000 In-Reply-To: <1384164875.3189.179.camel@kazak.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Matt Wilson Cc: Andrew Cooper , Roddy Rodstein , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org >>> On 11.11.13 at 11:14, Ian Campbell wrote: > On Sun, 2013-11-10 at 14:25 -0800, Matt Wilson wrote: >> On Thu, Oct 10, 2013 at 10:42:14AM +0100, Andrew Cooper wrote: >> > In the Xen model, domains are responsible for clearing any sensitive >> > data they have out of memory before shutdown. >> >> This isn't strictly true. Memory is scrubbed by Xen when the domain >> cannot do it for itself (i.e., when a domain is dying during >> shutdown). > > Isn't this only when the domain is killed by the toolstack or crashes > etc. On a graceful shutdown I thought the guest was still responsible > for clearing any memory it cared about. No, the scrubbing is independent of the shutdown reason: /* * Normally we expect a domain to clear pages before freeing them, if * it cares about the secrecy of their contents. However, after a * domain has died we assume responsibility for erasure. */ if ( unlikely(d->is_dying) ) for ( i = 0; i < (1 << order); i++ ) scrub_one_page(&pg[i]); Jan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Is there an issue with turning off "scrubbing free RAM" on boot with Xen 4.1.3 Date: Mon, 11 Nov 2013 10:47:56 +0000 Message-ID: <1384166876.8909.13.camel@kazak.uk.xensource.com> References: <52559F56.3070901@mokumsolutions.com> <52567676.3010102@citrix.com> <20131110222511.GA22949@u109add4315675089e695.ant.amazon.com> <1384164875.3189.179.camel@kazak.uk.xensource.com> <5280C0730200007800101B69@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vfp2I-0003V0-7c for xen-devel@lists.xenproject.org; Mon, 11 Nov 2013 10:48:02 +0000 In-Reply-To: <5280C0730200007800101B69@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Roddy Rodstein , Matt Wilson , xen-devel@lists.xenproject.org, Andrew Cooper List-Id: xen-devel@lists.xenproject.org On Mon, 2013-11-11 at 10:33 +0000, Jan Beulich wrote: > >>> On 11.11.13 at 11:14, Ian Campbell wrote: > > On Sun, 2013-11-10 at 14:25 -0800, Matt Wilson wrote: > >> On Thu, Oct 10, 2013 at 10:42:14AM +0100, Andrew Cooper wrote: > >> > In the Xen model, domains are responsible for clearing any sensitive > >> > data they have out of memory before shutdown. > >> > >> This isn't strictly true. Memory is scrubbed by Xen when the domain > >> cannot do it for itself (i.e., when a domain is dying during > >> shutdown). > > > > Isn't this only when the domain is killed by the toolstack or crashes > > etc. On a graceful shutdown I thought the guest was still responsible > > for clearing any memory it cared about. > > No, the scrubbing is independent of the shutdown reason: > > /* > * Normally we expect a domain to clear pages before freeing them, if > * it cares about the secrecy of their contents. However, after a > * domain has died we assume responsibility for erasure. > */ > if ( unlikely(d->is_dying) ) > for ( i = 0; i < (1 << order); i++ ) > scrub_one_page(&pg[i]); My mistake, thanks for the correction. This does seem safer/wiser in any case... Ian.