tls: rx: don't report text length from the bowels of decrypt
authorJakub Kicinski <kuba@kernel.org>
Fri, 8 Apr 2022 18:31:25 +0000 (11:31 -0700)
committerDavid S. Miller <davem@davemloft.net>
Sun, 10 Apr 2022 16:32:11 +0000 (17:32 +0100)
commit9bdf75ccffa690237cd0b472cd598cf6d22873dc
treea0bc324249adf544edabc9e73a67061ddd07b9b2
parentd4bd88e67666c73cfa9d75c282e708890d4f10a7
tls: rx: don't report text length from the bowels of decrypt

We plumb pointer to chunk all the way to the decryption method.
It's set to the length of the text when decrypt_skb_update()
returns.

I think the code is written this way because original TLS
implementation passed &chunk to zerocopy_from_iter() and this
was carried forward as the code gotten more complex, without
any refactoring.

The fix for peek() introduced a new variable - to_decrypt
which for all practical purposes is what chunk is going to
get set to. Spare ourselves the pointer passing, use to_decrypt.

Use this opportunity to clean things up a little further.

Note that chunk / to_decrypt was mostly needed for the async
path, since the sync path would access rxm->full_len (decryption
transforms full_len from record size to text size). Use the
right source of truth more explicitly.

We have three cases:
 - async - it's TLS 1.2 only, so chunk == to_decrypt, but we
           need the min() because to_decrypt is a whole record
   and we don't want to underflow len. Note that we can't
   handle partial record by falling back to sync as it
   would introduce reordering against records in flight.
 - zc - again, TLS 1.2 only for now, so chunk == to_decrypt,
        we don't do zc if len < to_decrypt, no need to check again.
 - normal - it already handles chunk > len, we can factor out the
            assignment to rxm->full_len and share it with zc.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/tls/tls_sw.c