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