| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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@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.
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home