thr3ads.net - Xen devel - [Xen-devel] Academic Project [Feb 2009]

If this information is useful, please help other people find it:
Share via:

dinesh chandrasekaran

2009-Feb-22 17:19 UTC

[Xen-devel] Academic Project

Hi Folks,
               I''m developing a secure memory manager module for xen as
a part of my academic project.
 Thereby protecting DomU memory by moving the trust for memory protection from
Dom0 to hardware by encrypting/
 decrypting the guest memory on per-domain-secret key basis and realizing the
same using a crypto coprocessor (FPGA)
 with necessary software (XEN) hooks and interfaces.

 Now one of the implementation issues is that how to move the domU memory
allocation (both boot pages and application pages)
 to fall behind the coprocessor by modifying xen source. If so where in the
source tree the changes have to be made.

 I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.
 Since I have allocate real memory to domU, I am clueless.
 
 I would appreciate you If you could send me your valuable suggestions.

Thanks,
Dinesh C

_________________________________________________________________
Chose your Life Partner! Join MSN Matrimony FREE
http://www.in.msn.com/matrimony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Feb-23 15:31 UTC

head link

[Xen-devel] Academic Project

From: dinesh_chan8@hotmail.com
To: michal@rsbac.org
Subject: RE: [Xen-devel] Academic Project
Date: Mon, 23 Feb 2009 00:46:01 +0530

Essentially, first step towards minimizing the trusted computing base. 

Assuming the VMM is not compromised (after a secure boot), domU doesnt have to
trust dom0.

For example, the following command issued from dom0 would dump the guest memory
in dom0 hard disk,
                     xm save Guest guest_mem.dump

Using the crypto coprocessor, this can be encrypted, so that only domU can
read/write and not dom0.
The result of the above command will store an encrypted dump file on the dom0
disk.

Thanks,
Dinesh C
From: michal@rsbac.org
To: dinesh_chan8@hotmail.com
Subject: Re: [Xen-devel] Academic Project
Date: Sun, 22 Feb 2009 19:31:32 +0100

And what is the purpose of this?Seems to be trivial to get over it.

Sent from my iPhone
On Feb 22, 2009, at 6:19 PM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:

Hi Folks,
               I''m developing a secure memory manager module for xen as
a part of my academic project.
 Thereby protecting DomU memory by moving the trust for memory protection from
Dom0 to hardware by encrypting/
 decrypting the guest memory on per-domain-secret key basis and realizing the
same using a crypto coprocessor (FPGA)
 with necessary software (XEN) hooks and interfaces.

 Now one of the implementation issues is that how to move the domU memory
allocation (both boot pages and application pages)
 to fall behind the coprocessor by modifying xen source. If so where in the
source tree the changes have to be made.

 I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.
 Since I have allocate real memory to domU, I am clueless.

 I would appreciate you If you could send me your valuable suggestions.

Thanks,
Dinesh C

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!
_________________________________________________________________
Find a better job. We have plenty. Visit MSN Jobs
http://www.in.msn.com/jobs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

weiming

2009-Feb-23 15:44 UTC

head link

Re: [Xen-devel] Academic Project

I''m curious about the crypto coprocessor. Does it work like a memory
controller? So every memory read/write will be encrypted/decrypted by it?

Thanks,
Weiming

On Mon, Feb 23, 2009 at 10:31 AM, dinesh chandrasekaran <
dinesh_chan8@hotmail.com> wrote:
>
>
> ------------------------------
> From: dinesh_chan8@hotmail.com
> To: michal@rsbac.org
> Subject: RE: [Xen-devel] Academic Project
> Date: Mon, 23 Feb 2009 00:46:01 +0530
>
> Essentially, first step towards minimizing the trusted computing base.
>
> Assuming the VMM is not compromised (after a secure boot), domU doesnt have
> to trust dom0.
>
> For example, the following command issued from dom0 would dump the guest
> memory in dom0 hard disk,
>                      xm save Guest guest_mem.dump
>
> Using the crypto coprocessor, this can be encrypted, so that only domU can
> read/write and not dom0.
> The result of the above command will store an encrypted dump file on the
> dom0 disk.
>
> Thanks,
> Dinesh C
> ------------------------------
> From: michal@rsbac.org
> To: dinesh_chan8@hotmail.com
> Subject: Re: [Xen-devel] Academic Project
> Date: Sun, 22 Feb 2009 19:31:32 +0100
>
> And what is the purpose of this?
> Seems to be trivial to get over it.
>
> Sent from my iPhone
>
> On Feb 22, 2009, at 6:19 PM, dinesh chandrasekaran <
> dinesh_chan8@hotmail.com> wrote:
>
> Hi Folks,
>                I''m developing a secure memory manager module for
xen as a
> part of my academic project.
>  Thereby protecting DomU memory by moving the trust for memory protection
> from Dom0 to hardware by encrypting/
>  decrypting the guest memory on per-domain-secret key basis and realizing
> the same using a crypto coprocessor (FPGA)
>  with necessary software (XEN) hooks and interfaces.
>
>  Now one of the implementation issues is that how to move the domU memory
> allocation (both boot pages and application pages)
>  to fall behind the coprocessor by modifying xen source. If so where in the
> source tree the changes have to be made.
>
>  I did try modifying common/memory.c : populate_physmap(), but I am afraid
> this is not the right place.
>  Since I have allocate real memory to domU, I am clueless.
>
>  I would appreciate you If you could send me your valuable suggestions.
>
> Thanks,
> Dinesh C
>
> ------------------------------
> Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on
> MSN Entertainment! Check it out! <http://entertainment.in.msn.com>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> ------------------------------
> Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on
> MSN Entertainment! Check it out! <http://entertainment.in.msn.com>
> ------------------------------
> Get a view of the world through MSN Video. Some things just cannot be left
> unseen. Try it! <http://video.msn.com/?mkt=en-in>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Feb-23 16:07 UTC

head link

RE: [Xen-devel] Academic Project

Yes. It will appear to be another PCI device sitting between the CPU and guest
memory.

To achieve this I need to make sure that xen allocates guest memory from memory
behind the crypto coprocessor.
This is the implementation issue I need to solve to get the project going.

I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.

Since I have allocate real memory to domU, I am clueless.

Thanks,
Dinesh C
Date: Mon, 23 Feb 2009 10:44:34 -0500
Subject: Re: [Xen-devel] Academic Project
From: zephyr.zhao@gmail.com
To: dinesh_chan8@hotmail.com
CC: xen-devel@lists.xensource.com

I''m curious about the crypto coprocessor. Does it work like a memory
controller? So every memory read/write will be encrypted/decrypted by it?

Thanks,
Weiming

On Mon, Feb 23, 2009 at 10:31 AM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:








From: dinesh_chan8@hotmail.com
To: michal@rsbac.org
Subject: RE: [Xen-devel] Academic Project

Date: Mon, 23 Feb 2009 00:46:01 +0530








Essentially, first step towards minimizing the trusted computing base. 

Assuming the VMM is not compromised (after a secure boot), domU doesnt have to
trust dom0.

For example, the following command issued from dom0 would dump the guest memory
in dom0 hard disk,

                     xm save Guest guest_mem.dump

Using the crypto coprocessor, this can be encrypted, so that only domU can
read/write and not dom0.
The result of the above command will store an encrypted dump file on the dom0
disk.


Thanks,
Dinesh C
From: michal@rsbac.org
To: dinesh_chan8@hotmail.com
Subject: Re: [Xen-devel] Academic Project

Date: Sun, 22 Feb 2009 19:31:32 +0100

And what is the purpose of this?Seems to be trivial to get over it.

Sent from my iPhone
On Feb 22, 2009, at 6:19 PM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:



Hi Folks,
               I''m developing a secure memory manager module for xen as
a part of my academic project.
 Thereby protecting DomU memory by moving the trust for memory protection from
Dom0 to hardware by encrypting/

 decrypting the guest memory on per-domain-secret key basis and realizing the
same using a crypto coprocessor (FPGA)
 with necessary software (XEN) hooks and interfaces.

 Now one of the implementation issues is that how to move the domU memory
allocation (both boot pages and application pages)

 to fall behind the coprocessor by modifying xen source. If so where in the
source tree the changes have to be made.

 I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.

 Since I have allocate real memory to domU, I am clueless.
 
 I would appreciate you If you could send me your valuable suggestions.

Thanks,
Dinesh C

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!

Get a view of the world through MSN Video. Some things just cannot be left
unseen. Try it!

_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel




_________________________________________________________________
Chose your Life Partner! Join MSN Matrimony FREE
http://www.in.msn.com/matrimony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

weiming

2009-Feb-23 16:17 UTC

head link

Re: [Xen-devel] Academic Project

One more thing is that the device should be able to tell if the access is
from the owner of protected domain or from others (like dom0). If the dom0
is compromised, it may mimic the request from that domU.

Weiming



On Mon, Feb 23, 2009 at 11:07 AM, dinesh chandrasekaran <
dinesh_chan8@hotmail.com> wrote:
>  Yes. It will appear to be another PCI device sitting between the CPU and
> guest memory.
>
> To achieve this I need to make sure that xen allocates guest memory from
> memory behind the crypto coprocessor.
> This is the implementation issue I need to solve to get the project going.
>
> I did try modifying common/memory.c : populate_physmap(), but I am afraid
> this is not the right place.
> Since I have allocate real memory to domU, I am clueless.
>
> Thanks,
> Dinesh C
> ------------------------------
> Date: Mon, 23 Feb 2009 10:44:34 -0500
> Subject: Re: [Xen-devel] Academic Project
> From: zephyr.zhao@gmail.com
> To: dinesh_chan8@hotmail.com
> CC: xen-devel@lists.xensource.com
>
>
> I''m curious about the crypto coprocessor. Does it work like a
memory
> controller? So every memory read/write will be encrypted/decrypted by it?
>
> Thanks,
> Weiming
>
> On Mon, Feb 23, 2009 at 10:31 AM, dinesh chandrasekaran <
> dinesh_chan8@hotmail.com> wrote:
>
>
>
> ------------------------------
> From: dinesh_chan8@hotmail.com
> To: michal@rsbac.org
> Subject: RE: [Xen-devel] Academic Project
> Date: Mon, 23 Feb 2009 00:46:01 +0530
>
> Essentially, first step towards minimizing the trusted computing base.
>
> Assuming the VMM is not compromised (after a secure boot), domU doesnt have
> to trust dom0.
>
> For example, the following command issued from dom0 would dump the guest
> memory in dom0 hard disk,
>                      xm save Guest guest_mem.dump
>
> Using the crypto coprocessor, this can be encrypted, so that only domU can
> read/write and not dom0.
> The result of the above command will store an encrypted dump file on the
> dom0 disk.
>
> Thanks,
> Dinesh C
> ------------------------------
> From: michal@rsbac.org
> To: dinesh_chan8@hotmail.com
> Subject: Re: [Xen-devel] Academic Project
> Date: Sun, 22 Feb 2009 19:31:32 +0100
>
> And what is the purpose of this?
> Seems to be trivial to get over it.
>
> Sent from my iPhone
>
> On Feb 22, 2009, at 6:19 PM, dinesh chandrasekaran <
> dinesh_chan8@hotmail.com> wrote:
>
> Hi Folks,
>                I''m developing a secure memory manager module for
xen as a
> part of my academic project.
>  Thereby protecting DomU memory by moving the trust for memory protection
> from Dom0 to hardware by encrypting/
>  decrypting the guest memory on per-domain-secret key basis and realizing
> the same using a crypto coprocessor (FPGA)
>  with necessary software (XEN) hooks and interfaces.
>
>  Now one of the implementation issues is that how to move the domU memory
> allocation (both boot pages and application pages)
>  to fall behind the coprocessor by modifying xen source. If so where in the
> source tree the changes have to be made.
>
>  I did try modifying common/memory.c : populate_physmap(), but I am afraid
> this is not the right place.
>  Since I have allocate real memory to domU, I am clueless.
>
>  I would appreciate you If you could send me your valuable suggestions.
>
> Thanks,
> Dinesh C
>
> ------------------------------
> Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on
> MSN Entertainment! Check it out! <http://entertainment.in.msn.com>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> ------------------------------
> Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on
> MSN Entertainment! Check it out! <http://entertainment.in.msn.com>
> ------------------------------
> Get a view of the world through MSN Video. Some things just cannot be left
> unseen. Try it! <http://video.msn.com/?mkt=en-in>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>
> ------------------------------
> Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on
> MSN Entertainment! Check it out! <http://entertainment.in.msn.com>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Feb-23 16:41 UTC

head link

[Xen-devel] Academic Project

Absolutly. This could be achieved through xen hooks which informs the device
about the currently scheduled domain.
This would prevent the guest memory from compromised dom0.

Dinesh C
Date: Mon, 23 Feb 2009 11:16:22 -0500
Subject: Re: [Xen-devel] Academic Project
From: zephyr.zhao@gmail.com
To: dinesh_chan8@hotmail.com

One more thing is that the device should be able to tell if the access is from
the owner of protected domain or from others (like dom0). If the dom0 is
compromised, it may mimic the request from that domU.

Weiming

On Mon, Feb 23, 2009 at 11:07 AM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:

Yes. It will appear to be another PCI device sitting between the CPU and guest
memory.

To achieve this I need to make sure that xen allocates guest memory from memory
behind the crypto coprocessor.
This is the implementation issue I need to solve to get the project going.

I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.

Since I have allocate real memory to domU, I am clueless.

Thanks,
Dinesh C
Date: Mon, 23 Feb 2009 10:44:34 -0500
Subject: Re: [Xen-devel] Academic Project
From: zephyr.zhao@gmail.com

To: dinesh_chan8@hotmail.com
CC: xen-devel@lists.xensource.com

I''m curious about the crypto coprocessor. Does it work like a memory
controller? So every memory read/write will be encrypted/decrypted by it?

Thanks,
Weiming

On Mon, Feb 23, 2009 at 10:31 AM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:

From: dinesh_chan8@hotmail.com
To: michal@rsbac.org
Subject: RE: [Xen-devel] Academic Project

Date: Mon, 23 Feb 2009 00:46:01 +0530

Essentially, first step towards minimizing the trusted computing base. 

Assuming the VMM is not compromised (after a secure boot), domU doesnt have to
trust dom0.

For example, the following command issued from dom0 would dump the guest memory
in dom0 hard disk,

                     xm save Guest guest_mem.dump

Using the crypto coprocessor, this can be encrypted, so that only domU can
read/write and not dom0.
The result of the above command will store an encrypted dump file on the dom0
disk.

Thanks,
Dinesh C
From: michal@rsbac.org
To: dinesh_chan8@hotmail.com
Subject: Re: [Xen-devel] Academic Project

Date: Sun, 22 Feb 2009 19:31:32 +0100

And what is the purpose of this?Seems to be trivial to get over it.

Sent from my iPhone
On Feb 22, 2009, at 6:19 PM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:

Hi Folks,
               I''m developing a secure memory manager module for xen as
a part of my academic project.
 Thereby protecting DomU memory by moving the trust for memory protection from
Dom0 to hardware by encrypting/

 decrypting the guest memory on per-domain-secret key basis and realizing the
same using a crypto coprocessor (FPGA)
 with necessary software (XEN) hooks and interfaces.

 Now one of the implementation issues is that how to move the domU memory
allocation (both boot pages and application pages)

 to fall behind the coprocessor by modifying xen source. If so where in the
source tree the changes have to be made.

 I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.

 Since I have allocate real memory to domU, I am clueless.

 I would appreciate you If you could send me your valuable suggestions.

Thanks,
Dinesh C

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!

Get a view of the world through MSN Video. Some things just cannot be left
unseen. Try it!

_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!

_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel

Rediscover the magic of Windows & WIN a Windows Vista laptop & Windows
mobile phone at www.windowsandme.com Try it now!
_________________________________________________________________
Wish to Marry Now? Join MSN Matrimony FREE!
http://www.in.msn.com/matrimony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Mar-03 19:54 UTC

head link

RE: [Xen-devel] Academic Project

Can some one tell me how to go about achieving this.

How to allocate real memory (which is behind a PCI device) to guests?
I need to modify Xen source to achieve the above. 
where exactly in the source I should do so?

Thanks,
Dinesh C
From: dinesh_chan8@hotmail.com
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Academic Project
Date: Mon, 23 Feb 2009 22:11:53 +0530

Absolutly. This could be achieved through xen hooks which informs the device
about the currently scheduled domain.
This would prevent the guest memory from compromised dom0.

Dinesh C
Date: Mon, 23 Feb 2009 11:16:22 -0500
Subject: Re: [Xen-devel] Academic Project
From: zephyr.zhao@gmail.com
To: dinesh_chan8@hotmail.com

One more thing is that the device should be able to tell if the access is from
the owner of protected domain or from others (like dom0). If the dom0 is
compromised, it may mimic the request from that domU.

Weiming

On Mon, Feb 23, 2009 at 11:07 AM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:

Yes. It will appear to be another PCI device sitting between the CPU and guest
memory.

To achieve this I need to make sure that xen allocates guest memory from memory
behind the crypto coprocessor.
This is the implementation issue I need to solve to get the project going.

I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.

Since I have allocate real memory to domU, I am clueless.

Thanks,
Dinesh C
Date: Mon, 23 Feb 2009 10:44:34 -0500
Subject: Re: [Xen-devel] Academic Project
From: zephyr.zhao@gmail.com

To: dinesh_chan8@hotmail.com
CC: xen-devel@lists.xensource.com

I''m curious about the crypto coprocessor. Does it work like a memory
controller? So every memory read/write will be encrypted/decrypted by it?

Thanks,
Weiming

On Mon, Feb 23, 2009 at 10:31 AM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:

From: dinesh_chan8@hotmail.com
To: michal@rsbac.org
Subject: RE: [Xen-devel] Academic Project

Date: Mon, 23 Feb 2009 00:46:01 +0530

Essentially, first step towards minimizing the trusted computing base. 

Assuming the VMM is not compromised (after a secure boot), domU doesnt have to
trust dom0.

For example, the following command issued from dom0 would dump the guest memory
in dom0 hard disk,

                     xm save Guest guest_mem.dump

Using the crypto coprocessor, this can be encrypted, so that only domU can
read/write and not dom0.
The result of the above command will store an encrypted dump file on the dom0
disk.

Thanks,
Dinesh C
From: michal@rsbac.org
To: dinesh_chan8@hotmail.com
Subject: Re: [Xen-devel] Academic Project

Date: Sun, 22 Feb 2009 19:31:32 +0100

And what is the purpose of this?Seems to be trivial to get over it.

Sent from my iPhone
On Feb 22, 2009, at 6:19 PM, dinesh chandrasekaran
<dinesh_chan8@hotmail.com> wrote:

Hi Folks,
               I''m developing a secure memory manager module for xen as
a part of my academic project.
 Thereby protecting DomU memory by moving the trust for memory protection from
Dom0 to hardware by encrypting/

 decrypting the guest memory on per-domain-secret key basis and realizing the
same using a crypto coprocessor (FPGA)
 with necessary software (XEN) hooks and interfaces.

 Now one of the implementation issues is that how to move the domU memory
allocation (both boot pages and application pages)

 to fall behind the coprocessor by modifying xen source. If so where in the
source tree the changes have to be made.

 I did try modifying common/memory.c : populate_physmap(), but I am afraid this
is not the right place.

 Since I have allocate real memory to domU, I am clueless.

 I would appreciate you If you could send me your valuable suggestions.

Thanks,
Dinesh C

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!

Get a view of the world through MSN Video. Some things just cannot be left
unseen. Try it!

_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel

Akshay Kumar takes on the two reigning Bollywood Khans. Catch the action on MSN
Entertainment! Check it out!

_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel

Rediscover the magic of Windows & WIN a Windows Vista laptop & Windows
mobile phone at www.windowsandme.com Try it now!
Need more space to upload pictures? Get 25 GB online storage with Windows Live
SkyDrive! Try it!
_________________________________________________________________
Express your true emotions! Send a virtual kiss! Do all these cool stuff &
more with Windows Live Messenger. Download here
http://www.windowslive.com/Desktop/Messenger

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Mats Petersson

2009-Mar-03 20:17 UTC

head link

RE: [Xen-devel] Academic Project

I''m absolutely not sure I follow what you are trying to do, but if 
what you want to do is "hide" a device in a particular domain, and 
give the memory "behind" that device to the domain, then that is not 
likely to work. You can only "get to" memory hidden behind a PCI 
device if you can turn the PCI device off. Turning the device off is 
of course a valid option if the device is not needed at all by the 
system. If it is needed, then you have no option but to leave it 
enabled, and the physical memory behind the device will be hidden by 
the PCI device.

There are certain memory controller chipsets (e.g. the memory 
controller integrated into the Athlon64/Opteron/etc models after Rev 
E or so) that have "hidden memory hoisting", which essentially means 
that you can tell the memory controller that "take the memory behind 
the PCI device in this range, and move it up a bit", which means that 
if you have (say) 4GB of RAM, and a PCI bus hole of 768MB, the system 
will appear to have memory from 0-3.25GB, then PCI devices for 
0.75GB, and then another 0.75GB of RAM.

--
Mats

At 19:54 03/03/2009, dinesh chandrasekaran wrote:>Can some one tell me how to go about achieving this.
>
>How to allocate real memory (which is behind a PCI device) to guests?
>I need to modify Xen source to achieve the above.
>where exactly in the source I should do so?
>
>Thanks,
>Dinesh C
>
>----------
>From: dinesh_chan8@hotmail.com
>To: xen-devel@lists.xensource.com
>Subject: [Xen-devel] Academic Project
>Date: Mon, 23 Feb 2009 22:11:53 +0530
>
>
>Absolutly. This could be achieved through xen hooks which informs 
>the device about the currently scheduled domain.
>This would prevent the guest memory from compromised dom0.
>
>Dinesh C
>
>----------
>Date: Mon, 23 Feb 2009 11:16:22 -0500
>Subject: Re: [Xen-devel] Academic Project
>From: zephyr.zhao@gmail.com
>To: dinesh_chan8@hotmail.com
>
>One more thing is that the device should be able to tell if the 
>access is from the owner of protected domain or from others (like 
>dom0). If the dom0 is compromised, it may mimic the request from that domU.
>
>Weiming
>
>On Mon, Feb 23, 2009 at 11:07 AM, dinesh chandrasekaran 
><<mailto:dinesh_chan8@hotmail.com>dinesh_chan8@hotmail.com>
wrote:
>Yes. It will appear to be another PCI device sitting between the CPU 
>and guest memory.
>
>To achieve this I need to make sure that xen allocates guest memory 
>from memory behind the crypto coprocessor.
>This is the implementation issue I need to solve to get the project going.
>
>
>I did try modifying common/memory.c : populate_physmap(), but I am 
>afraid this is not the right place.
>Since I have allocate real memory to domU, I am clueless.
>
>Thanks,
>Dinesh C
>
>----------
>Date: Mon, 23 Feb 2009 10:44:34 -0500
>
>Subject: Re: [Xen-devel] Academic Project
>From: <mailto:zephyr.zhao@gmail.com>zephyr.zhao@gmail.com
>
>To: <mailto:dinesh_chan8@hotmail.com>dinesh_chan8@hotmail.com
>CC:
<mailto:xen-devel@lists.xensource.com>xen-devel@lists.xensource.com
>
>
>I''m curious about the crypto coprocessor. Does it work like a
memory
>controller? So every memory read/write will be encrypted/decrypted by it?
>
>Thanks,
>Weiming
>
>On Mon, Feb 23, 2009 at 10:31 AM, dinesh chandrasekaran 
><<mailto:dinesh_chan8@hotmail.com>dinesh_chan8@hotmail.com>
wrote:
>
>
>
>----------
>From: <mailto:dinesh_chan8@hotmail.com>dinesh_chan8@hotmail.com
>To: <mailto:michal@rsbac.org>michal@rsbac.org
>Subject: RE: [Xen-devel] Academic Project
>Date: Mon, 23 Feb 2009 00:46:01 +0530
>
>Essentially, first step towards minimizing the trusted computing base.
>
>Assuming the VMM is not compromised (after a secure boot), domU 
>doesnt have to trust dom0.
>
>For example, the following command issued from dom0 would dump the 
>guest memory in dom0 hard disk,
>                      xm save Guest guest_mem.dump
>
>Using the crypto coprocessor, this can be encrypted, so that only 
>domU can read/write and not dom0.
>The result of the above command will store an encrypted dump file on 
>the dom0 disk.
>
>Thanks,
>Dinesh C
>
>----------
>From: <mailto:michal@rsbac.org>michal@rsbac.org
>To: <mailto:dinesh_chan8@hotmail.com>dinesh_chan8@hotmail.com
>Subject: Re: [Xen-devel] Academic Project
>Date: Sun, 22 Feb 2009 19:31:32 +0100
>
>And what is the purpose of this?
>Seems to be trivial to get over it.
>
>Sent from my iPhone
>
>On Feb 22, 2009, at 6:19 PM, dinesh chandrasekaran 
><<mailto:dinesh_chan8@hotmail.com>dinesh_chan8@hotmail.com>
wrote:
>
>Hi Folks,
>                I''m developing a secure memory manager module for 
> xen as a part of my academic project.
>  Thereby protecting DomU memory by moving the trust for memory 
> protection from Dom0 to hardware by encrypting/
>  decrypting the guest memory on per-domain-secret key basis and 
> realizing the same using a crypto coprocessor (FPGA)
>  with necessary software (XEN) hooks and interfaces.
>
>  Now one of the implementation issues is that how to move the domU 
> memory allocation (both boot pages and application pages)
>  to fall behind the coprocessor by modifying xen source. If so 
> where in the source tree the changes have to be made.
>
>  I did try modifying common/memory.c : populate_physmap(), but I am 
> afraid this is not the right place.
>  Since I have allocate real memory to domU, I am clueless.
>
>  I would appreciate you If you could send me your valuable suggestions.
>
>Thanks,
>Dinesh C
>
>
>----------
>Akshay Kumar takes on the two reigning Bollywood Khans. Catch the 
>action on MSN Entertainment! <http://entertainment.in.msn.com>Check it
out!
>
>_______________________________________________
>Xen-devel mailing list
><mailto:Xen-devel@lists.xensource.com>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>
>
>----------
>Akshay Kumar takes on the two reigning Bollywood Khans. Catch the 
>action on MSN Entertainment! <http://entertainment.in.msn.com>Check it
out!
>
>----------
>Get a view of the world through MSN Video. Some things just cannot 
>be left unseen. <http://video.msn.com/?mkt=en-in>Try it!
>
>_______________________________________________
>Xen-devel mailing list
><mailto:Xen-devel@lists.xensource.com>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>
>
>
>----------
>Akshay Kumar takes on the two reigning Bollywood Khans. Catch the 
>action on MSN Entertainment! <http://entertainment.in.msn.com>Check it
out!
>
>_______________________________________________
>Xen-devel mailing list
><mailto:Xen-devel@lists.xensource.com>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>
>
>
>----------
>Rediscover the magic of Windows & WIN a Windows Vista laptop & 
>Windows mobile phone at www.windowsandme.com 
><http://www.windowsandme.com>Try it now!
>
>----------
>Need more space to upload pictures? Get 25 GB online storage with 
>Windows Live SkyDrive! <http://windowslive.com/Online/SkyDrive>Try it!
>
>----------
>Keep an eye on the world around you and on the bigger picture, 
><http://news.in.msn.com/>Try it now!
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Leber

2009-Mar-03 22:54 UTC

head link

Re: [Xen-devel] Academic Project

On Wed, Mar 04, 2009 at 01:24:46AM +0530, dinesh chandrasekaran
wrote:>    Can some one tell me how to go about achieving this.
First: I''m sorry, but i''m pretty sure that what you want to
do... will
never work in a "normal" computer.
IMO the dom0 usually can access everything and all hardware, but it does
not matter as soon as it can access some hardware that can do DMA an
attacker may find an attack vector.

And i also don''t see any application, why should the hypervisor be
trusted, but not the dom0?
>    How to allocate real memory (which is behind a PCI device) to guests?
>    I need to modify Xen source to achieve the above.
You want map memory from a PCI device in the address room?

That is no problem, despite that the maximum bar size (that will work on
many systems) is 256 MB (i have seen a single system were 1 GB was
working, probably there are others, no idea)
And by PIO reading you''ll get like 10-20 MB/s or something like that.

Anyway (shameless plug) for such low level stuff i would not suggest to
use PCI, but a real interface like HyperTransport.

There is a HTX board, that offers advantages compared to a PCI board.
http://ra.ziti.uni-heidelberg.de/index.php?page=projects&id=htx

Christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Mar-04 00:30 UTC

head link

RE: [Xen-devel] Academic Project

And i also don''t see any application, why should the hypervisor be
trusted, but not the dom0?

I claim that the purpose of the proposed technique is due to the following
reasons.
1) dom0 is another linux kernel which runs in ring 3 (IA64) along with other
guests with more privileges.
2) It runs the management tools (xm) which is the point of user interaction for
desktop virtualization.

Hence the goal is to protect the guest memory/state from compromised dom0.

By the way, I''m sorry I use PCIe board and not PCI .

regards,
Dinesh C
> Date: Tue, 3 Mar 2009 23:54:12 +0100
> From: christian@leber.de
> To: dinesh_chan8@hotmail.com
> Subject: Re: [Xen-devel] Academic Project
> CC: xen-devel@lists.xensource.com
> 
> On Wed, Mar 04, 2009 at 01:24:46AM +0530, dinesh chandrasekaran wrote:
> >    Can some one tell me how to go about achieving this.
> 
> First: I''m sorry, but i''m pretty sure that what you want
to do... will
> never work in a "normal" computer.
> IMO the dom0 usually can access everything and all hardware, but it does
> not matter as soon as it can access some hardware that can do DMA an
> attacker may find an attack vector.
> 
> And i also don''t see any application, why should the hypervisor be
> trusted, but not the dom0?
> 
> >    How to allocate real memory (which is behind a PCI device) to
guests?
> >    I need to modify Xen source to achieve the above.
> 
> You want map memory from a PCI device in the address room?
> 
> That is no problem, despite that the maximum bar size (that will work on
> many systems) is 256 MB (i have seen a single system were 1 GB was
> working, probably there are others, no idea)
> And by PIO reading you''ll get like 10-20 MB/s or something like
that.
> 
> 
> Anyway (shameless plug) for such low level stuff i would not suggest to
> use PCI, but a real interface like HyperTransport.
> 
> There is a HTX board, that offers advantages compared to a PCI board.
> http://ra.ziti.uni-heidelberg.de/index.php?page=projects&id=htx
> 
> 
> Christian
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_________________________________________________________________
Ready for MARRIAGE? Join MSN Matrimony!
http://www.shaadi.com/msn/matrimony.php?ptnr=msnhottag

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Leber

2009-Mar-04 00:55 UTC

head link

Re: [Xen-devel] Academic Project

On Wed, Mar 04, 2009 at 06:00:40AM +0530, dinesh chandrasekaran wrote:

Hi dinesh
>    1) dom0 is another linux kernel which runs in ring 3 (IA64) along with
>    other guests with more privileges.
>    2) It runs the management tools (xm) which is the point of user
>    interaction for desktop virtualization.
>    Hence the goal is to protect the guest memory/state from compromised
dom0.
That implies the protection hardware is not controlled by the dom0 and
there is another more secure way for the administration of it and second
that the dom0 can''t do anything.

The dom0 can afaik do basically anything, so it also can claim
"i''m
secure domU No. 2 and i want my data!", furthermore the dom0 should also be
able to overwrite the xen kernel.
>    By the way, I''m sorry I use PCIe board and not PCI .
Does not matter, it has the same latency, you''ll get 10-20 MB/s memory
performance.


Christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Mar-04 02:55 UTC

head link

RE: [Xen-devel] Academic Project

Christian,
> That implies the protection hardware is not controlled by the dom0 and
> there is another more secure way for the administration of it and second
> that the dom0 can''t do anything.
Absolutely. You are correct.
> The dom0 can afaik do basically anything, so it also can claim
"i''m
> secure domU No. 2 and i want my data!", furthermore the dom0 should
also be
> able to overwrite the xen kernel.
I guess the domain scheduling is done by the VMM and not by dom0?
Through VMM Hooks, the VMM is made to inform the device about the domain
scheduled to run.
So dom0 cannot claim to be any domU.
> furthermore the dom0 should also be able to overwrite the xen kernel.
Can you throw some lights on the above "overwriting the xen kernel by
dom0"?

regards,
Dinesh C
> Date: Wed, 4 Mar 2009 01:55:36 +0100
> From: christian@leber.de
> To: dinesh_chan8@hotmail.com
> CC: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Academic Project
> 
> On Wed, Mar 04, 2009 at 06:00:40AM +0530, dinesh chandrasekaran wrote:
> 
> Hi dinesh
> 
> >    1) dom0 is another linux kernel which runs in ring 3 (IA64) along
with
> >    other guests with more privileges.
> >    2) It runs the management tools (xm) which is the point of user
> >    interaction for desktop virtualization.
> >    Hence the goal is to protect the guest memory/state from
compromised dom0.
> 
> That implies the protection hardware is not controlled by the dom0 and
> there is another more secure way for the administration of it and second
> that the dom0 can''t do anything.
> 
> The dom0 can afaik do basically anything, so it also can claim
"i''m
> secure domU No. 2 and i want my data!", furthermore the dom0 should
also be
> able to overwrite the xen kernel.
> 
> >    By the way, I''m sorry I use PCIe board and not PCI .
> 
> Does not matter, it has the same latency, you''ll get 10-20 MB/s
memory
> performance.
> 
> 
> Christian
_________________________________________________________________
Property Requirements? Available on MSN Real Estate
http://www.makaan.com/msn/real-estate.php?ptnr=mk0113

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xia, Liangfu

2009-Mar-04 05:15 UTC

head link

[Xen-devel] Volume group "VolGroup00" not found when I boot xen

Hi,
         Does anyone meet the problem above?
         My boot options:
                  tttle xen-3.3.1
                            root (hd0,0)
                            kernel /xen-3.3..1.gx
                            module /vimlinuz-2.6.18.8-xen ro
root=/dev/VolGroup00/LogVol00 rhgb quiet
                            module /initrd-2.6.18.8-xen.img

         All the required files are present in /boot, but it still
can''t work:(
         Can anyone help me with this problem?
Thanks


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Masaki Kanno

2009-Mar-04 05:49 UTC

head link

Re: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

Wed, 4 Mar 2009 13:15:24 +0800, "Xia, Liangfu" wrote:
>Hi,
>         Does anyone meet the problem above?
>         My boot options:
>                  tttle xen-3.3.1
typo?  tttle -> title

Thanks
 Kan

>                            root (hd0,0)
>                            kernel /xen-3.3..1.gx
>                            module /vimlinuz-2.6.18.8-xen ro root=/dev/
>VolGroup00/LogVol00 rhgb quiet
>                            module /initrd-2.6.18.8-xen.img
>
>         All the required files are present in /boot, but it still
can''t
>work:(
>         Can anyone help me with this problem?
>Thanks
>
>-------------------------------text/plain-------------------------------
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xia, Liangfu

2009-Mar-04 06:06 UTC

head link

RE: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

Sorry, it is title. When I write this mail, I make this mistake.
Do you have any ideas about it?
Thanks

-----Original Message-----
From: Masaki Kanno [mailto:kanno.masaki@jp.fujitsu.com] 
Sent: 2009年3月4日 13:50
To: Xia, Liangfu; xen developers community
Subject: Re: [Xen-devel] Volume group "VolGroup00" not found when I
boot xen

Wed, 4 Mar 2009 13:15:24 +0800, "Xia, Liangfu" wrote:
>Hi,
>         Does anyone meet the problem above?
>         My boot options:
>                  tttle xen-3.3.1
typo?  tttle -> title

Thanks
 Kan

>                            root (hd0,0)
>                            kernel /xen-3.3..1.gx
>                            module /vimlinuz-2.6.18.8-xen ro root=/dev/
>VolGroup00/LogVol00 rhgb quiet
>                            module /initrd-2.6.18.8-xen.img
>
>         All the required files are present in /boot, but it still can't
>work:(
>         Can anyone help me with this problem?
>Thanks
>
>-------------------------------text/plain-------------------------------
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

M A Young

2009-Mar-04 08:36 UTC

head link

Re: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

On Wed, 4 Mar 2009, Xia, Liangfu wrote:
> 
> Hi,
> 
>          Does anyone meet the problem above?
> 
>          My boot options:
> 
>                   tttle xen-3.3.1
> 
>                             root (hd0,0)
> 
>                             kernel /xen-3.3..1.gx
> 
>                             module /vimlinuz-2.6.18.8-xen ro
> root=/dev/VolGroup00/LogVol00 rhgb quiet
> 
>                             module /initrd-2.6.18.8-xen.img
> 
>  
> 
>          All the required files are present in /boot, but it still can?t
> workL
> 
>          Can anyone help me with this problem?
"VolGroup00 not found" may simply mean that the kernel can''t
see the
hard disk because some required modules are missing from the initrd and 
VolGroup00 is simply the first thing to complain about it. Of course the 
missing modules could also be the lvm related ones.

 	Michael Young
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Leber

2009-Mar-04 08:45 UTC

head link

Re: [Xen-devel] Academic Project

On Wed, Mar 04, 2009 at 08:25:49AM +0530, dinesh chandrasekaran wrote:

Hi dinesh
>    > That implies the protection hardware is not controlled by the dom0
and
>    > there is another more secure way for the administration of it and
second
>    > that the dom0 can''t do anything.
> 
>    Absolutely. You are correct.
Ok, so how do you plan to do this and why is this supposed to be more
secure?
>    I guess the domain scheduling is done by the VMM and not by dom0?
>    Through VMM Hooks, the VMM is made to inform the device about the domain
>    scheduled to run.
>    So dom0 cannot claim to be any domU.
I''m not really sure, but i think the dom0 can access the complete
system
memory. If not, then it controls at least some hardware that can do DMA
and can this way access all the memory.

-> dom0 can write/read all memory -> it can do anything
>    > furthermore the dom0 should also be able to overwrite the xen
kernel.
> 
>    Can you throw some lights on the above "overwriting the xen kernel
by
>    dom0"?
A compromised dom0 could just replace the xen kernel/hypervisor on disk and/or
in
memory.

Your idea just has so many problems, like what are you doing to do about disk
i/o?


Christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Boris Derzhavets

2009-Mar-04 09:11 UTC

head link

Re: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

/xen-3.3..1.gz--- On Wed, 3/4/09, M A Young <m.a.young@durham.ac.uk>
wrote:
From: M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Volume group "VolGroup00" not found when I
boot xen
To: "Xia, Liangfu" <liangfu.xia@intel.com>
Cc: "xen developers community" <xen-devel@lists.xensource.com>
Date: Wednesday, March 4, 2009, 3:36 AM

On Wed, 4 Mar 2009, Xia, Liangfu wrote:
> 
> Hi,
> 
>          Does anyone meet the problem above?
> 
>          My boot options:
> 
>                   tttle xen-3.3.1
> 
>                             root (hd0,0)
> 
>                             kernel
/xen-3.3..1.gx> 
>                             module
/vimlinuz-2.6.18.8-xen ro> root=/dev/VolGroup00/LogVol00 rhgb quiet
> 
>                             module
/initrd-2.6.18.8-xen.img> 
>  
> 
>          All the required files are present in /boot, but it still
can?t> workL
> 
>          Can anyone help me with this problem?
"VolGroup00 not found" may simply mean that the kernel can''t
see
the hard disk because some required modules are missing from the initrd and
VolGroup00 is simply the first thing to complain about it. Of course the missing
modules could also be the lvm related ones.

	Michael Young_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Mar-04 16:41 UTC

head link

RE: [Xen-devel] Academic Project

Christian,

Xen talks to the protection hardware behind which all the guest memory exists.
This is more secure because,
now if do the following you cannot extract any useful information
1) xm save Guest guest.dump (assuming a guest named "Guest" is already
running)
 this would dump the guest memory into a file in the dom0 disk.
2) Strings on guest.dump

Since this guest.dump is encrypted by the protection hardware, and Xen just
informed that "dom0 is running",
the encypted memory will only be released to dom0. This will be dumped into s
file in dom0 disk.
> If not, then it controls at least some hardware that can do DMA
> and can this way access all the memory.
You are correct. I will have to figure out a way in future to protect against
such type of DMA attacks.
> A compromised dom0 could just replace the xen kernel/hypervisor on disk
and/or in memory.
I think the secure boot using TPM would solve this issue of booting up a
"replaced" xen kernel.

This project is just a prototype and I will have to work more to resolve all
issues.
Thanks so much for your suggestions.

regards,
Dinesh C
> Date: Wed, 4 Mar 2009 09:45:58 +0100
> From: christian@leber.de
> To: dinesh_chan8@hotmail.com
> Subject: Re: [Xen-devel] Academic Project
> CC: xen-devel@lists.xensource.com
> 
> On Wed, Mar 04, 2009 at 08:25:49AM +0530, dinesh chandrasekaran wrote:
> 
> Hi dinesh
> 
> >    > That implies the protection hardware is not controlled by the
dom0 and
> >    > there is another more secure way for the administration of it
and second
> >    > that the dom0 can''t do anything.
> > 
> >    Absolutely. You are correct.
> 
> Ok, so how do you plan to do this and why is this supposed to be more
> secure?
> 
> >    I guess the domain scheduling is done by the VMM and not by dom0?
> >    Through VMM Hooks, the VMM is made to inform the device about the
domain
> >    scheduled to run.
> >    So dom0 cannot claim to be any domU.
> 
> I''m not really sure, but i think the dom0 can access the complete
system
> memory. If not, then it controls at least some hardware that can do DMA
> and can this way access all the memory.
> 
> -> dom0 can write/read all memory -> it can do anything
> 
> >    > furthermore the dom0 should also be able to overwrite the xen
kernel.
> > 
> >    Can you throw some lights on the above "overwriting the xen
kernel by
> >    dom0"?
> 
> A compromised dom0 could just replace the xen kernel/hypervisor on disk
and/or in
> memory.
> 
> Your idea just has so many problems, like what are you doing to do about
disk i/o?
> 
> 
> Christian
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_________________________________________________________________
Ready for MARRIAGE? Join MSN Matrimony!
http://www.shaadi.com/msn/matrimony.php?ptnr=msnhottag

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Leber

2009-Mar-05 08:47 UTC

head link

Re: [Xen-devel] Academic Project

On Wed, Mar 04, 2009 at 10:11:41PM +0530, dinesh chandrasekaran wrote:

Hi dinesh
>    Xen talks to the protection hardware behind which all the guest memory
>    exists.
The memory is mapped.

And i was wrong, the dom0 can''t just access all memory in the system.
>    This is more secure because,
>    now if do the following you cannot extract any useful information
>    1) xm save Guest guest.dump (assuming a guest named "Guest" is
already
>    running)
>     this would dump the guest memory into a file in the dom0 disk.
>    2) Strings on guest.dump
So encrypt it in the Xen kernel.
>    Since this guest.dump is encrypted by the protection hardware, and Xen
>    just informed that "dom0 is running",
That assumes that the dom0 always has to run alone on the machine, in 2009 the
minimum server has 8 cores (next year 12) and often more.
>    the encypted memory will only be released to dom0. This will be dumped
>    into s file in dom0 disk.
Ok, so by taking a step back and looking at the problem again, i think
you are basically facing two possibilities:

1.) The security of the Xen kernel is brocken
    -> You are lost, your hardware can''t protect anything.

2.) The security of the Xen kernel is not brocke
    -> Why on earth hardware? What you can do in Verilog on an FPGA, can
       be done much more conveniently in C in the Xen kernel.
       (Don''t get me wrong, I''m all pro building hardware.)

Encypting in hardware gets interesting again when you want to try to protect
against physical attacks to the system. (assuming very good case intrusion
detection)
>    > If not, then it controls at least some hardware that can do DMA
>    > and can this way access all the memory.
>    You are correct. I will have to figure out a way in future to protect
>    against such type of DMA attacks.
Well, solutions exist most likely in the form of IOMMUs.


Christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Mar-05 20:46 UTC

head link

RE: [Xen-devel] Academic Project

Assuming the following, 
1) security of the Xen kernel is not brocken (through TPMs)
2) I need to protect against physical attacks to the system (because we have a
very good intrusion detection system in place).
    So I''m going with Verilog in FPGA.
3) IOMMUs protecting against DMA attacks.

Where in the xen source should I modify code to allocate guest memory from
memory behind the FPGA and not "general" mem pool?

Christian, I appreciate your participation and valuable suggestions (They will
definitely find a place in my report).

regards,
Dinesh C
> Encypting in hardware gets interesting again when you want to try to
protect
> against physical attacks to the system. (assuming very good case intrusion
> detection)
> Date: Thu, 5 Mar 2009 09:47:05 +0100
> From: christian@leber.de
> To: dinesh_chan8@hotmail.com
> Subject: Re: [Xen-devel] Academic Project
> CC: xen-devel@lists.xensource.com
> 
> On Wed, Mar 04, 2009 at 10:11:41PM +0530, dinesh chandrasekaran wrote:
> 
> Hi dinesh
> 
> >    Xen talks to the protection hardware behind which all the guest
memory
> >    exists.
> 
> The memory is mapped.
> 
> And i was wrong, the dom0 can''t just access all memory in the
system.
> 
> >    This is more secure because,
> >    now if do the following you cannot extract any useful information
> >    1) xm save Guest guest.dump (assuming a guest named
"Guest" is already
> >    running)
> >     this would dump the guest memory into a file in the dom0 disk.
> >    2) Strings on guest.dump
> 
> So encrypt it in the Xen kernel.
> 
> >    Since this guest.dump is encrypted by the protection hardware, and
Xen
> >    just informed that "dom0 is running",
> 
> That assumes that the dom0 always has to run alone on the machine, in 2009
the
> minimum server has 8 cores (next year 12) and often more.
> 
> >    the encypted memory will only be released to dom0. This will be
dumped
> >    into s file in dom0 disk.
> 
> Ok, so by taking a step back and looking at the problem again, i think
> you are basically facing two possibilities:
> 
> 1.) The security of the Xen kernel is brocken
>     -> You are lost, your hardware can''t protect anything.
> 
> 2.) The security of the Xen kernel is not brocke
>     -> Why on earth hardware? What you can do in Verilog on an FPGA, can
>        be done much more conveniently in C in the Xen kernel.
>        (Don''t get me wrong, I''m all pro building
hardware.)
> 
> Encypting in hardware gets interesting again when you want to try to
protect
> against physical attacks to the system. (assuming very good case intrusion
> detection)
> 
> >    > If not, then it controls at least some hardware that can do
DMA
> >    > and can this way access all the memory.
> >    You are correct. I will have to figure out a way in future to
protect
> >    against such type of DMA attacks.
> 
> Well, solutions exist most likely in the form of IOMMUs.
> 
> 
> Christian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_________________________________________________________________
Windows Live Messenger. Multitasking at its finest.
http://www.microsoft.com/india/windows/windowslive/messenger.aspx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

dinesh chandrasekaran

2009-Mar-09 19:29 UTC

head link

[Xen-devel] Academic Project

Assuming the following, 
1) security of the Xen kernel is not brocken (through TPMs)
2) I need to protect against physical attacks to the system (because we have a
very good intrusion detection system in place).
    So I''m going with Verilog in FPGA.
3) IOMMUs protecting against DMA attacks.

Where in the xen source should I modify code to allocate guest memory from
memory behind the FPGA and not "general" mem pool?

Christian, I appreciate your participation and valuable suggestions (They will
definitely find a place in my report).

regards,
Dinesh C
> Encypting in hardware gets interesting again when you want to try to
protect
> against physical attacks to the system. (assuming very good case intrusion
> detection)
> Date: Thu, 5 Mar 2009 09:47:05 +0100
> From: christian@leber.de
> To: dinesh_chan8@hotmail.com
> Subject: Re: [Xen-devel] Academic Project
> CC: xen-devel@lists.xensource.com
> 
> On Wed, Mar 04, 2009 at 10:11:41PM +0530, dinesh chandrasekaran wrote:
> 
> Hi dinesh
> 
> >    Xen talks to the protection hardware behind which all the guest
memory
> >    exists.
> 
> The memory is mapped.
> 
> And i was wrong, the dom0 can''t just access all memory in the
system.
> 
> >    This is more secure because,
> >    now if do the following you cannot extract any useful information
> >    1) xm save Guest guest.dump (assuming a guest named
"Guest" is already
> >    running)
> >     this would dump the guest memory into a file in the dom0 disk.
> >    2) Strings on guest.dump
> 
> So encrypt it in the Xen kernel.
> 
> >    Since this guest.dump is encrypted by the protection hardware, and
Xen
> >    just informed that "dom0 is running",
> 
> That assumes that the dom0 always has to run alone on the machine, in 2009
the
> minimum server has 8 cores (next year 12) and often more.
> 
> >    the encypted memory will only be released to dom0. This will be
dumped
> >    into s file in dom0 disk.
> 
> Ok, so by taking a step back and looking at the problem again, i think
> you are basically facing two possibilities:
> 
> 1.) The security of the Xen kernel is brocken
>     -> You are lost, your hardware can''t protect anything.
> 
> 2.) The security of the Xen kernel is not brocke
>     -> Why on earth hardware? What you can do in Verilog on an FPGA, can
>        be done much more conveniently in C in the Xen kernel.
>        (Don''t get me wrong, I''m all pro building
hardware.)
> 
> Encypting in hardware gets interesting again when you want to try to
protect
> against physical attacks to the system. (assuming very good case intrusion
> detection)
> 
> >    > If not, then it controls at least some hardware that can do
DMA
> >    > and can this way access all the memory.
> >    You are correct. I will have to figure out a way in future to
protect
> >    against such type of DMA attacks.
> 
> Well, solutions exist most likely in the form of IOMMUs.
> 
> 
> Christian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
Windows Live Messenger.  Multitasking at its finest.
_________________________________________________________________
Windows Live Messenger. Multitasking at its finest.
http://www.microsoft.com/india/windows/windowslive/messenger.aspx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Xen devel - Feb 2009 - Academic Project

[Xen-devel] Academic Project

[Xen-devel] Academic Project

Re: [Xen-devel] Academic Project

RE: [Xen-devel] Academic Project

Re: [Xen-devel] Academic Project

[Xen-devel] Academic Project

RE: [Xen-devel] Academic Project

RE: [Xen-devel] Academic Project

Re: [Xen-devel] Academic Project

RE: [Xen-devel] Academic Project

Re: [Xen-devel] Academic Project

RE: [Xen-devel] Academic Project

[Xen-devel] Volume group "VolGroup00" not found when I boot xen

Re: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

RE: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

Re: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

Re: [Xen-devel] Academic Project

Re: [Xen-devel] Volume group "VolGroup00" not found when I boot xen

RE: [Xen-devel] Academic Project

Re: [Xen-devel] Academic Project

RE: [Xen-devel] Academic Project

[Xen-devel] Academic Project