From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1G9-0001JT-FV for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:48:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ1G5-0008Ei-5m for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:48:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1G4-0008Ec-Tu for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:48:49 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14EmmoS031994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 09:48:48 -0500 Message-ID: <54D2314C.7010501@redhat.com> Date: Wed, 04 Feb 2015 16:48:44 +0200 From: Marcel Apfelbaum MIME-Version: 1.0 References: <20150204113229.GN3032@redhat.com> <20150204130821.GH2329@work-vm> <20150204140259.GR3032@redhat.com> <54D22C86.8050100@redhat.com> In-Reply-To: <54D22C86.8050100@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , "Daniel P. Berrange" , "Dr. David Alan Gilbert" Cc: amit.shah@redhat.com, Marcel Apfelbaum , qemu-devel@nongnu.org, quintela@redhat.com 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 h= ooks >>> that go around the back of QEMUFile in migration, and it's transferri= ng 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 in >> the RDMA based channel ? I don't know enough about RDMA myself to know >> if it makes sense or not, other than the fact that any channel between >> two separate hosts needs security at some level in the stack. > > Authentication, possibly; but I don't think encryption makes sense. Ma= rcel? I personally think that the protocol is safe enough, but as always there = are holes and I am not a security expert: "RDMA mechanisms can create a potential security vulnerability. A no= de may access another nodes memory region that was supposed to be banned. In order to protect remote memory access to unauthorized memory are= as, InfiniBand defines memory protection mechanisms, where a remote memory access requires a spec= ial 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." More on Layer 2 attacks and how Infiniband handle those: http://www.mellanox.com/related-docs/whitepapers/WP_Secuirty_In_Infi= niBand_Fabrics_Final.pdf I hope I helped, Marcel > > Paolo >