WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[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@xxxxxxxx
> To: dinesh_chan8@xxxxxxxxxxx
> Subject: Re: [Xen-devel] Academic Project
> CC: xen-devel@xxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


Windows Live Messenger. Multitasking at its finest.

Windows Live Messenger. Multitasking at its finest.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel