All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
To: George Dunlap <George.Dunlap@eu.citrix.com>,
	Xen-devel@lists.xensource.com
Subject: Re: RAM security
Date: Mon, 06 Dec 2010 15:35:49 +0000	[thread overview]
Message-ID: <4CFD02D5.7080903@abpni.co.uk> (raw)
In-Reply-To: <AANLkTinVW1NNkNkqYaeyi08dBX+iPTRbipv7+AG4sFUZ@mail.gmail.com>

Just a few questions:

1) By saying "the guest's responsibility", does this mean that 
CONFIG_XEN_SCRUB_PAGES=y is set in the DomU kernel config?

2) Also, if a DomU was shutdown by xm destroy, obviously the DomU 
wouldn’t scrub the RAM. However would Xen still scrub the RAM?

3) If the physical server was shutdown (e.g. plug pulled), I'm guessing 
this will presetn a problem?

4) Why doesn't Xen scrub the RAM before giving it to the DomU?

Thanks

On 06/12/10 14:49, George Dunlap wrote:
> I looked into this sometime this last year.  I believe the answer is
> "no": the domain destruction routines will zero memory before handing
> it back to Xen.
>
> One potential data leak, however (last time I looked at this), is that
> Xen does not scrub memory handed back by the balloon driver.  So if
> the guest OS hasn't scrubbed it, and it contains sensitive
> information, it may end up being assigned to another domain as-is
> (either via ballooning or start-of-day domain creation).  At the
> moment that's considered the guest's responsibility.
>
>   -George
>
> On Mon, Dec 6, 2010 at 2:35 PM, Jonathan Tripathy<jonnyt@abpni.co.uk>  wrote:
>> Hi Everyone,
>>
>> In Xen, is a DomU able to access data in RAM which a previous DomU has
>> stored in the past, but didn't "zero" it?
>>
>> I understand that this is a problem with physical disks (using phy:/), just
>> wondering if the same stands with RAM
>>
>> Thanks
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>

  parent reply	other threads:[~2010-12-06 15:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <46C13AA90DB8844DAB79680243857F0F0AFF44@server1.ABPNI.local>
2010-12-06 14:35 ` RAM security Jonathan Tripathy
2010-12-06 14:49   ` George Dunlap
2010-12-06 15:13     ` Jonathan Tripathy
2010-12-06 15:35     ` Jonathan Tripathy [this message]
2010-12-06 16:26       ` Keir Fraser
2010-12-06 16:31         ` Jonathan Tripathy
2010-12-06 16:52           ` Keir Fraser
2010-12-06 16:53             ` Jonathan Tripathy
2010-12-06 17:05             ` Jan Beulich
2010-12-06 17:12               ` Jonathan Tripathy
2010-12-06 17:17                 ` Jonathan Tripathy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CFD02D5.7080903@abpni.co.uk \
    --to=jonnyt@abpni.co.uk \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.