Linux cryptographic layer development
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: netdev@vger.kernel.org, linux-crypto@vger.kernel.org
Cc: dhowells@redhat.com, viro@zeniv.linux.org.uk
Subject: How best to {en,de}crypt between sk_buff and iov_iter?
Date: Wed, 10 Aug 2016 10:12:12 +0100	[thread overview]
Message-ID: <9009.1470820332@warthog.procyon.org.uk> (raw)

Is there a good way to encrypt data held in an iov_iter directly into an
sk_buff and decrypt data held in an sk_buff back into an iov_iter?

What I would like to avoid is:

 (a) Invoking skb_cow_data() to potentially take an unnecessary copy of the
     data I shouldn't need to change, but I need to do this to decrypt in
     place.

 (b) Having to copy the unencrypted data between the sk_buff and the iov_iter
     when the crypto process ought to get me a free copy.

One problem, though, is that I might not be able to do drain/fill a complete
sk_buff in a single operation because the iov_iter might not give me sufficient
bufferage/data to do that, so it may take multiple operations.  However, since
I'm using an skcipher, I think it should be fine to call
crypto_skcipher_encrypt() multiple times on the same skcipher.

I can see a couple of alternatives:

 (1) Duplicate skb_copy_datagram_iter(), give it an initialised
     skcipher_request and let it set the crypto parameters for each block it
     transfers.  copy_to_iter() would then need to be replaced with something
     that sets up an sglist each time from the iov.

     Something similar would need doing for skb_copy_datagram_from_iter().

 (2) Create an sglist for the skb and one for the iov_iter and encrypt/decrypt
     between them.  Unfortunately, if the iov_iter is a userspace reference
     then this would mean pinning userspace pages.

 (3) Add an {en,de}crypt-to-iov_iter capability to the crypto layer.  I'm not
     sure how well this would work for hardware support, though.  I think we'd
     come back to pinning userspace pages.

David

                 reply	other threads:[~2016-08-10  9:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9009.1470820332@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox