ktls / af_ktls

Linux Kernel TLS/DTLS Module
GNU General Public License v2.0
159 stars 25 forks source link

check sock_queue_rcv_skb return value #75

Closed lancerchao closed 8 years ago

lancerchao commented 8 years ago

sock_queue_rcv_skb, which appends the decrypted data to the sk->sk_receive_queue can fail if the queue is full.

In DTLS we can just drop the packet and free it. In TLS we can't. One strategy to use to have a temporary location to store 1 skb if receive queue is full. Then we "pause" data processing until sk_receive_queue is no longer full. The wake up can happen for example in tls_recvmsg

Another simpler way is to proactively check whether the receive queue would be full before trying to add it to receive queue. For example, during tls_read_size.

lancerchao commented 8 years ago

I'll work on this and add a test case for it.

fridex commented 8 years ago

The simplier way looks much cleaner.

BTW not sure with TCP queuing. Using skbuffs in ktls would lead to have two kernel buffers - that means we double the kernel memory that can be used for data per single socket instance. Would that be an issue?

EDIT: This shouldn't be an issue since we are decrypting only requested size + we store only data that were not read by user space, but were part of the decrypted record.

lancerchao commented 8 years ago

74 This would also solve this issue. If we can read from TCP sock without pulling data off, we can just pause and pull the data off later when KTLS sk_receive_queue is not full

djwatson commented 8 years ago

This should be fixed in https://github.com/ktls/af_ktls/pull/76