summaryrefslogtreecommitdiff
path: root/io/channel-tls.c
AgeCommit message (Collapse)AuthorFilesLines
2018-11-19io: return 0 for EOF in TLS session read after shutdownDaniel P. Berrangé1-0/+5
GNUTLS takes a paranoid approach when seeing 0 bytes returned by the underlying OS read() function. It will consider this an error and return GNUTLS_E_PREMATURE_TERMINATION instead of propagating the 0 return value. It expects apps to arrange for clean termination at the protocol level and not rely on seeing EOF from a read call to detect shutdown. This is to harden apps against a malicious 3rd party causing termination of the sockets layer. This is unhelpful for the QEMU NBD code which does have a clean protocol level shutdown, but still relies on seeing 0 from the I/O channel read in the coroutine handling incoming replies. The upshot is that when using a plain NBD connection shutdown is silent, but when using TLS, the client spams the console with Cannot read from TLS channel: Broken pipe The NBD connection has, however, called qio_channel_shutdown() at this point to indicate that it is done with I/O. This gives the opportunity to optimize the code such that when the channel has been shutdown in the read direction, the error code GNUTLS_E_PREMATURE_TERMINATION gets turned into a '0' return instead of an error. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20181119134228.11031-1-berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-06qio: non-default context for TLS handshakePeter Xu1-11/+34
A new parameter "context" is added to qio_channel_tls_handshake() is to allow the TLS to be run on a non-default context. Still, no functional change. Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2017-02-21io: add methods to set I/O handlers on AioContextPaolo Bonzini1-0/+12
This is in preparation for making qio_channel_yield work on AioContexts other than the main one. Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20170213135235.12274-6-pbonzini@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-23io: change the QIOTask callback signatureDaniel P. Berrange1-8/+6
Currently the QIOTaskFunc signature takes an Object * for the source, and an Error * for any error. We also need to be able to provide a result pointer. Rather than continue to add parameters to QIOTaskFunc, remove the existing ones and simply pass the QIOTask object instead. This has methods to access all the other data items required in the callback impl. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-01-23io: stop incrementing reference in qio_task_get_sourceDaniel P. Berrange1-2/+0
Incrementing the reference in qio_task_get_source is not necessary, since we're not running concurrently with any other code touching the QIOTask. This minimizes chances of further memory leaks. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-10-26io: Introduce a qio_channel_set_feature() helperFelipe Franciosi1-1/+1
Testing QIOChannel feature support can be done with a helper called qio_channel_has_feature(). Setting feature support, however, was done manually with a logical OR. This patch introduces a new helper called qio_channel_set_feature() and makes use of it where applicable. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-10-26io: Use qio_channel_has_feature() where applicableFelipe Franciosi1-1/+1
Parts of the code have been testing QIOChannel features directly with a logical AND. This patch makes it all consistent by using the qio_channel_has_feature() function to test if a feature is present. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-03-22include/qemu/osdep.h: Don't include qapi/error.hMarkus Armbruster1-0/+1
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the Error typedef. Since then, we've moved to include qemu/osdep.h everywhere. Its file comment explains: "To avoid getting into possible circular include dependencies, this file should not include any other QEMU headers, with the exceptions of config-host.h, compiler.h, os-posix.h and os-win32.h, all of which are doing a similar job to this file and are under similar constraints." qapi/error.h doesn't do a similar job, and it doesn't adhere to similar constraints: it includes qapi-types.h. That's in excess of 100KiB of crap most .c files don't actually need. Add the typedef to qemu/typedefs.h, and include that instead of qapi/error.h. Include qapi/error.h in .c files that need it and don't get it now. Include qapi-types.h in qom/object.h for uint16List. Update scripts/clean-includes accordingly. Update it further to match reality: replace config.h by config-target.h, add sysemu/os-posix.h, sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h comment quoted above similarly. This reduces the number of objects depending on qapi/error.h from "all of them" to less than a third. Unfortunately, the number depending on qapi-types.h shrinks only a little. More work is needed for that one. Signed-off-by: Markus Armbruster <armbru@redhat.com> [Fix compilation without the spice devel packages. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-02-04io: Clean up includesPeter Maydell1-0/+1
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1454089805-5470-14-git-send-email-peter.maydell@linaro.org
2015-12-18io: add QIOChannelTLS classDaniel P. Berrange1-0/+393
Add a QIOChannel subclass that can run the TLS protocol over the top of another QIOChannel instance. The object provides a simplified API to perform the handshake when starting the TLS session. The layering of TLS over the underlying channel does not have to be setup immediately. It is possible to take an existing QIOChannel that has done some handshake and then swap in the QIOChannelTLS layer. This allows for use with protocols which start TLS right away, and those which start plain text and then negotiate TLS. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>