Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

[Wouter Verhelst <w@uter.be>]

On Thu, Apr 07, 2016 at 02:56:48PM +0100, Daniel P. Berrange wrote:
> I don't really agree that there's a use case of mixing
> tls & non-tls exports in the same server.

There is: swap-on-NBD and TLS do not mix.

Without special handling, swapping to the network is prone to deadlocks,
because the machine doesn't know when a block of swapped data has been
written to disk until it receives and processes the ACK from the server
that tells it the data is safe. This means it must keep reading from the
server until that ACK is received. Since the reason you're paging memory
to your swap space is, most likely, the fact that you're low on memory,
swapping to the network while simultaneously trying to view a 4K video
from youtube will get you deadlocked in seconds.

To fix that, a PF_MEMALLOC kernel-level socket option was created a few
years ago. If the kernel is low on memory, it will drop all network
packets save those destined for a socket with that option set. In doing
so, the 4K youtube video data will be dropped until the low memory
situation is resolved, but the reply packet from the NBD server will
arrive.

However, only the kernel can set the PF_MEMALLOC socket option; and due
to the way in which we pass the nbd socket to the kernel, having it
decode the TLS conversation seems complicated, if it even is possible.
Therefore, decoding the TLS conversation when the client is going to be
the kernel, will need to be done in userspace. The nbd-client would need
to call socketpair(), fork(), pass one end of the pair in the child
process to the kernel, and be a decoding proxy in the parent.

Since you *need* to have non-TLS NBD if you want to support
non-deadlocking swapspace over the network (one of the major use cases
for NBD), you *need* to have a server which supports non-TLS NBD.

Requiring that a user uses two different NBD servers, one with TLS
enabled and one with TLS disabled, just so swapping to NBD is possible,
seems silly.

Therefore, the reference implementation is not going to *require* that
all exports do TLS if TLS is enabled; however, it *is* going to default
to that.

> > Incidentally, the qemu client does not appear to assume the
> > server is 'FORCEDTLS', and IIRC from time spend staring into
> > Wireshark yesterday sends its NBD_OPT_LIST prior to the TLS
> > upgrade. I can check that if you like.
> 
> If the qemu NBD client has TLS credentials set then it will
> refuse to connect to a server without TLS.

That seems like a valid and safe mode of operation.

> The OPT_TLS is definitely the first thing it sends, becasue the QEMU
> NBD server will reject all options until OPT_TLS has been sent.

So if I want to swap to qemu-nbd, I cannot also have encrypted
connections to the same server. Got it.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12