]> git.karo-electronics.de Git - linux-beck.git/commit
libceph: introduce ceph_crypt() for in-place en/decryption
authorIlya Dryomov <idryomov@gmail.com>
Fri, 2 Dec 2016 15:35:07 +0000 (16:35 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 26 Jan 2017 07:24:41 +0000 (08:24 +0100)
commitecf7ced8562811576cd02158d6ae8e44c1fb4671
treefef5843604cce3dd494664b1d23d47c0da786d3f
parent0548b82989384a58e749f0c04781b2c823c6c1b9
libceph: introduce ceph_crypt() for in-place en/decryption

commit a45f795c65b479b4ba107b6ccde29b896d51ee98 upstream.

Starting with 4.9, kernel stacks may be vmalloced and therefore not
guaranteed to be physically contiguous; the new CONFIG_VMAP_STACK
option is enabled by default on x86.  This makes it invalid to use
on-stack buffers with the crypto scatterlist API, as sg_set_buf()
expects a logical address and won't work with vmalloced addresses.

There isn't a different (e.g. kvec-based) crypto API we could switch
net/ceph/crypto.c to and the current scatterlist.h API isn't getting
updated to accommodate this use case.  Allocating a new header and
padding for each operation is a non-starter, so do the en/decryption
in-place on a single pre-assembled (header + data + padding) heap
buffer.  This is explicitly supported by the crypto API:

    "... the caller may provide the same scatter/gather list for the
     plaintext and cipher text. After the completion of the cipher
     operation, the plaintext data is replaced with the ciphertext data
     in case of an encryption and vice versa for a decryption."

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/ceph/crypto.c
net/ceph/crypto.h