Academic Project

Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 1065 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 1438 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 2430 bytes --]




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

[-- Attachment #1.2: Type: text/html, Size: 3566 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Academic Project

[weiming]

[-- Attachment #1.1: Type: text/plain, Size: 3102 bytes --]

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
>
>

[-- Attachment #1.2: Type: text/html, Size: 4466 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 3617 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 5296 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Academic Project

[weiming]

[-- Attachment #1.1: Type: text/plain, Size: 4457 bytes --]

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
>
>

[-- Attachment #1.2: Type: text/html, Size: 6467 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 4704 bytes --]










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

[-- Attachment #1.2: Type: text/html, Size: 7173 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 5302 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 7906 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Academic Project

[Mats Petersson]

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

Re: Academic Project

[Christian Leber]

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

RE: Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 2384 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 2824 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Academic Project

[Christian Leber]

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

RE: Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 2143 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 2567 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Volume group "VolGroup00" not found when I boot xen

[Xia, Liangfu]

[-- Attachment #1.1: Type: text/plain, Size: 509 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4921 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Volume group "VolGroup00" not found when I boot xen

[Masaki Kanno]

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

RE: Volume group "VolGroup00" not found when I boot xen

[Xia, Liangfu]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

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


[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Volume group "VolGroup00" not found when I boot xen

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 908 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Volume group "VolGroup00" not found when I boot xen

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1410 bytes --]

/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



      

[-- Attachment #1.2: Type: text/html, Size: 2662 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Academic Project

[Christian Leber]

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

RE: Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 2964 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 3515 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Academic Project

[Christian Leber]

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

RE: Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 3331 bytes --]


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

[-- Attachment #1.2: Type: text/html, Size: 3933 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Academic Project

[dinesh chandrasekaran]

[-- Attachment #1.1: Type: text/plain, Size: 3395 bytes --]







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

[-- Attachment #1.2: Type: text/html, Size: 4218 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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