Re: [libvirt] NBD TLS support in QEMU
[Cc: to nbd-general list added]
On Wed, Sep 03, 2014 at 05:44:17PM +0100, Stefan Hajnoczi wrote:
Hi,
QEMU offers both NBD client and server functionality. The NBD protocol
runs unencrypted, which is a problem when the client and server
communicate over an untrusted network.
The particular use case that prompted this mail is storage migration in
OpenStack. The goal is to encrypt the NBD connection between source and
destination hosts during storage migration.
I've never given encrypted NBD high priority, since I don't think
encryption without authentication serves much purpose -- and I haven't
gotten around to adding authentication yet (for which I have plans; but
other things have priority).
I think we can integrate TLS into the NBD protocol as an optional
flag.
A quick web search does not reveal existing open source SSL/TLS NBD
implementations. I do see a VMware NBDSSL protocol but there is no
specification so I guess it is proprietary.
The NBD protocol starts with a negotiation phase. This would be the
appropriate place to indicate that TLS will be used. After client and
server complete TLS setup the connection can continue as normal.
Besides QEMU, the userspace NBD tools (http://nbd.sf.net/) can also be
extended to support TLS. In this case the kernel needs a localhost
socket and userspace handles TLS.
That introduces a possibility for a deadlock, since now your network
socket isn't on the PF_MEMALLOC-protected socket anymore, which will
cause the kernel to throw away packets which are needed for your nbd
connection, in hopes of clearing some memory.
I suppose you could theoretically do the encryption in kernel space.
Not convinced that trying TLS in kernel space is a good idea, though.
I have heard of people using stunnel or the likes to pipe the NBD
protocol over a secure channel, with various levels of success.
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26