From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1IC-0002if-6G for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:51:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ1IB-0000aF-0k for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:51:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1IA-0000aA-OK for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:50:58 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14Eown2032761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 09:50:58 -0500 Date: Wed, 4 Feb 2015 14:50:53 +0000 From: "Daniel P. Berrange" Message-ID: <20150204145053.GW3032@redhat.com> References: <20150204113229.GN3032@redhat.com> <20150204130821.GH2329@work-vm> <20150204140259.GR3032@redhat.com> <54D22C86.8050100@redhat.com> <54D2314C.7010501@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54D2314C.7010501@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: Marcel Apfelbaum , quintela@redhat.com, "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, amit.shah@redhat.com, Paolo Bonzini On Wed, Feb 04, 2015 at 04:48:44PM +0200, Marcel Apfelbaum wrote: > On 02/04/2015 04:28 PM, Paolo Bonzini wrote: > > > > > >On 04/02/2015 15:02, Daniel P. Berrange wrote: > >>>I'm not sure if it makes sense for RDMA; it already has a couple of = hooks > >>>that go around the back of QEMUFile in migration, and it's transferr= ing the > >>>data via DMA so the page data doesn't go through the same path. > >> > >>Could you ever anticipate any need for authentication or encryption i= n > >>the RDMA based channel ? I don't know enough about RDMA myself to kno= w > >>if it makes sense or not, other than the fact that any channel betwee= n > >>two separate hosts needs security at some level in the stack. > > > >Authentication, possibly; but I don't think encryption makes sense. M= arcel? > I personally think that the protocol is safe enough, but as always ther= e are holes > and I am not a security expert: >=20 > "RDMA mechanisms can create a potential security vulnerability. A n= ode may access another nodes > memory region that was supposed to be banned. > In order to protect remote memory access to unauthorized memory ar= eas, InfiniBand defines memory > protection mechanisms, where a remote memory access requires a spe= cial key (R_Key). The R_Key is > negotiated between the peers and is validated at the target=E2=80=99= s system HCA card. In case of illegal key the > packet is dropped. The R_Key requirement is built into silicon and= driver code and cannot be disabled > even when attacker compromises root/admin/superuser account on one= or multiple servers." >=20 > More on Layer 2 attacks and how Infiniband handle those: > http://www.mellanox.com/related-docs/whitepapers/WP_Secuirty_In_Inf= iniBand_Fabrics_Final.pdf > Ok I guess we could probably just assume RDMA is sufficient as is for now. We can fairly easily revisit it later if we find it it needs more work Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|