Reverting crypto patches

entropy from the master key.  HKDF is also standardized and widely

used by other software, whereas the AES-128-ECB based KDF is ad-hoc.

Per-file encryption keys

------------------------

Per-file keys

-------------

Since each master key can protect many files, it is necessary to

"tweak" the encryption of each file so that the same plaintext in two

Therefore, to improve performance and save memory, for Adiantum a

"direct key" configuration is supported.  When the user has enabled

this by setting FSCRYPT_POLICY_FLAG_DIRECT_KEY in the fscrypt policy,

per-file encryption keys are not used.  Instead, whenever any data

(contents or filenames) is encrypted, the file's 16-byte nonce is

included in the IV.  Moreover:

per-file keys are not used.  Instead, whenever any data (contents or

filenames) is encrypted, the file's 16-byte nonce is included in the

IV.  Moreover:

- For v1 encryption policies, the encryption is done directly with the

  master key.  Because of this, users **must not** use the same master

identifier" is also derived using the KDF.  This value is stored in

the clear, since it is needed to reliably identify the key itself.

Dirhash keys

------------

For directories that are indexed using a secret-keyed dirhash over the

plaintext filenames, the KDF is also used to derive a 128-bit

SipHash-2-4 key per directory in order to hash filenames.  This works

just like deriving a per-file encryption key, except that a different

KDF context is used.  Currently, only casefolded ("case-insensitive")

encrypted directories use this style of hashing.

Encryption modes and usage

==========================

Adiantum is a (primarily) stream cipher-based mode that is fast even

on CPUs without dedicated crypto instructions.  It's also a true

wide-block mode, unlike XTS.  It can also eliminate the need to derive

per-file encryption keys.  However, it depends on the security of two

primitives, XChaCha12 and AES-256, rather than just one.  See the

paper "Adiantum: length-preserving encryption for entry-level

processors" (https://eprint.iacr.org/2018/720.pdf) for more details.

To use Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled.  Also, fast

per-file keys.  However, it depends on the security of two primitives,

XChaCha12 and AES-256, rather than just one.  See the paper

"Adiantum: length-preserving encryption for entry-level processors"

(https://eprint.iacr.org/2018/720.pdf) for more details.  To use

Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled.  Also, fast

implementations of ChaCha and NHPoly1305 should be enabled, e.g.

CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM.

- ``EEXIST``: the file is already encrypted with an encryption policy

  different from the one specified

- ``EINVAL``: an invalid encryption policy was specified (invalid

  version, mode(s), or flags; or reserved bits were set); or a v1

  encryption policy was specified but the directory has the casefold

  flag enabled (casefolding is incompatible with v1 policies).

  version, mode(s), or flags; or reserved bits were set)

- ``ENOKEY``: a v2 encryption policy was specified, but the key with

  the specified ``master_key_identifier`` has not been added, nor does

  the process have the CAP_FOWNER capability in the initial user

FS_IOC_GET_ENCRYPTION_PWSALT is deprecated.  Instead, prefer to

generate and manage any needed salt(s) in userspace.

Getting a file's encryption nonce

---------------------------------

Since Linux v5.7, the ioctl FS_IOC_GET_ENCRYPTION_NONCE is supported.

On encrypted files and directories it gets the inode's 16-byte nonce.

On unencrypted files and directories, it fails with ENODATA.

This ioctl can be useful for automated tests which verify that the

encryption is being done correctly.  It is not needed for normal use

of fscrypt.

Adding keys

-----------

    struct fscrypt_add_key_arg {

            struct fscrypt_key_specifier key_spec;

            __u32 raw_size;

            __u32 key_id;

            __u32 __reserved[8];

            __u32 __reserved[9];

            __u8 raw[];

    };

            } u;

    };

    struct fscrypt_provisioning_key_payload {

            __u32 type;

            __u32 __reserved;

            __u8 raw[];

    };

:c:type:`struct fscrypt_add_key_arg` must be zeroed, then initialized

as follows:

  ``Documentation/security/keys/core.rst``).

- ``raw_size`` must be the size of the ``raw`` key provided, in bytes.

  Alternatively, if ``key_id`` is nonzero, this field must be 0, since

  in that case the size is implied by the specified Linux keyring key.

- ``key_id`` is 0 if the raw key is given directly in the ``raw``

  field.  Otherwise ``key_id`` is the ID of a Linux keyring key of

  type "fscrypt-provisioning" whose payload is a :c:type:`struct

  fscrypt_provisioning_key_payload` whose ``raw`` field contains the

  raw key and whose ``type`` field matches ``key_spec.type``.  Since

  ``raw`` is variable-length, the total size of this key's payload

  must be ``sizeof(struct fscrypt_provisioning_key_payload)`` plus the

  raw key size.  The process must have Search permission on this key.

  Most users should leave this 0 and specify the raw key directly.

  The support for specifying a Linux keyring key is intended mainly to

  allow re-adding keys after a filesystem is unmounted and re-mounted,

  without having to store the raw keys in userspace memory.

- ``raw`` is a variable-length field which must contain the actual

  key, ``raw_size`` bytes long.  Alternatively, if ``key_id`` is

  nonzero, then this field is unused.

  key, ``raw_size`` bytes long.

For v2 policy keys, the kernel keeps track of which user (identified

by effective user ID) added the key, and only allows the key to be

- ``EACCES``: FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR was specified, but the

  caller does not have the CAP_SYS_ADMIN capability in the initial

  user namespace; or the raw key was specified by Linux key ID but the

  process lacks Search permission on the key.

  user namespace

- ``EDQUOT``: the key quota for this user would be exceeded by adding

  the key

- ``EINVAL``: invalid key size or key specifier type, or reserved bits

  were set

- ``EKEYREJECTED``: the raw key was specified by Linux key ID, but the

  key has the wrong type

- ``ENOKEY``: the raw key was specified by Linux key ID, but no key

  exists with that ID

- ``ENOTTY``: this type of filesystem does not implement encryption

- ``EOPNOTSUPP``: the kernel was not configured with encryption

  support for this filesystem, or the filesystem superblock has not

policy structs (see `Setting an encryption policy`_), except that the

context structs also contain a nonce.  The nonce is randomly generated

by the kernel and is used as KDF input or as a tweak to cause

different files to be encrypted differently; see `Per-file encryption

keys`_ and `DIRECT_KEY policies`_.

different files to be encrypted differently; see `Per-file keys`_ and

`DIRECT_KEY policies`_.

Data path changes

-----------------

allows the filesystem to still, with a high degree of confidence, map

the filename given in ->lookup() back to a particular directory entry

that was previously listed by readdir().  See :c:type:`struct

fscrypt_nokey_name` in the source for more details.

fscrypt_digested_name` in the source for more details.

Note that the precise way that filenames are presented to userspace

without the key is subject to change in the future.  It is only meant

	return false;

}

/*

 * Prepare blk-crypto-fallback for the specified crypto mode.

 * Returns -ENOPKG if the needed crypto API support is missing.

/**

 * blk_crypto_start_using_mode() - Start using a crypto algorithm on a device

 * @mode_num: the blk_crypto_mode we want to allocate ciphers for.

 * @data_unit_size: the data unit size that will be used

 * @q: the request queue for the device

 *

 * Upper layers must call this function to ensure that a the crypto API fallback

 * has transforms for this algorithm, if they become necessary.

 *

 * Return: 0 on success and -err on error.

 */

int blk_crypto_fallback_start_using_mode(enum blk_crypto_mode_num mode_num)

int blk_crypto_start_using_mode(enum blk_crypto_mode_num mode_num,

				unsigned int data_unit_size,

				struct request_queue *q)

{

	const char *cipher_str = blk_crypto_modes[mode_num].cipher_str;

	struct blk_crypto_keyslot *slotp;

	unsigned int i;

	int err = 0;

	if (likely(smp_load_acquire(&tfms_inited[mode_num])))

		return 0;

	/*

	 * If the keyslot manager of the request queue supports this

	 * crypto mode, then we don't need to allocate this mode.

	 */

	if (keyslot_manager_crypto_mode_supported(q->ksm, mode_num,

						  data_unit_size))

		return 0;

	mutex_lock(&tfms_init_lock);

	if (likely(tfms_inited[mode_num]))

		goto out;

	for (i = 0; i < blk_crypto_num_keyslots; i++) {

		slotp = &blk_crypto_keyslots[i];

		slotp->tfms[mode_num] = crypto_alloc_skcipher(cipher_str, 0, 0);

		slotp->tfms[mode_num] = crypto_alloc_skcipher(

					blk_crypto_modes[mode_num].cipher_str,

					0, 0);

		if (IS_ERR(slotp->tfms[mode_num])) {

			err = PTR_ERR(slotp->tfms[mode_num]);

			if (err == -ENOENT) {

				pr_warn_once("Missing crypto API support for \"%s\"\n",

					     cipher_str);

				err = -ENOPKG;

			}

			slotp->tfms[mode_num] = NULL;

			goto out_free_tfms;

		}

	mutex_unlock(&tfms_init_lock);

	return err;

}

EXPORT_SYMBOL_GPL(blk_crypto_start_using_mode);

int blk_crypto_fallback_evict_key(const struct blk_crypto_key *key)

{

	struct bio_crypt_ctx *bc = bio->bi_crypt_context;

	struct bio_fallback_crypt_ctx *f_ctx;

	if (bc->bc_key->is_hw_wrapped) {

		pr_warn_once("HW wrapped key cannot be used with fallback.\n");

		bio->bi_status = BLK_STS_NOTSUPP;

		return -EOPNOTSUPP;

	}

	if (!tfms_inited[bc->bc_key->crypto_mode]) {

		bio->bi_status = BLK_STS_IOERR;

		return -EIO;

		crypto_mode_supported[i] = 0xFFFFFFFF;

	crypto_mode_supported[BLK_ENCRYPTION_MODE_INVALID] = 0;

	blk_crypto_ksm = keyslot_manager_create(

				NULL, blk_crypto_num_keyslots,

	blk_crypto_ksm = keyslot_manager_create(NULL, blk_crypto_num_keyslots,

						&blk_crypto_ksm_ll_ops,

				BLK_CRYPTO_FEATURE_STANDARD_KEYS,

						crypto_mode_supported, NULL);

	if (!blk_crypto_ksm)

		return -ENOMEM;

#ifdef CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK

int blk_crypto_fallback_start_using_mode(enum blk_crypto_mode_num mode_num);

int blk_crypto_fallback_submit_bio(struct bio **bio_ptr);

bool blk_crypto_queue_decrypt_bio(struct bio *bio);

#else /* CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK */

static inline int

blk_crypto_fallback_start_using_mode(enum blk_crypto_mode_num mode_num)

{

	pr_warn_once("crypto API fallback is disabled\n");

	return -ENOPKG;

}

static inline bool bio_crypt_fallback_crypted(const struct bio_crypt_ctx *bc)

{

	return false;

	/* Get device keyslot if supported */

	if (keyslot_manager_crypto_mode_supported(q->ksm,

						  bc->bc_key->crypto_mode,

						  bc->bc_key->data_unit_size,

						  bc->bc_key->is_hw_wrapped)) {

						  bc->bc_key->data_unit_size)) {

		err = bio_crypt_ctx_acquire_keyslot(bc, q->ksm);

		if (!err)

			return 0;

 * @raw_key_size: Size of raw key.  Must be at least the required size for the

 *                chosen @crypto_mode; see blk_crypto_modes[].  (It's allowed

 *                to be longer than the mode's actual key size, in order to

 *                support inline encryption hardware that accepts wrapped keys.

 *                @is_hw_wrapped has to be set for such keys)

 * @is_hw_wrapped: Denotes @raw_key is wrapped.

 *                support inline encryption hardware that accepts wrapped keys.)

 * @crypto_mode: identifier for the encryption algorithm to use

 * @data_unit_size: the data unit size to use for en/decryption

 *

 */

int blk_crypto_init_key(struct blk_crypto_key *blk_key,

			const u8 *raw_key, unsigned int raw_key_size,

			bool is_hw_wrapped,

			enum blk_crypto_mode_num crypto_mode,

			unsigned int data_unit_size)

{

	BUILD_BUG_ON(BLK_CRYPTO_MAX_WRAPPED_KEY_SIZE < BLK_CRYPTO_MAX_KEY_SIZE);

	mode = &blk_crypto_modes[crypto_mode];

	if (is_hw_wrapped) {

	if (raw_key_size < mode->keysize ||

	    raw_key_size > BLK_CRYPTO_MAX_WRAPPED_KEY_SIZE)

		return -EINVAL;

	} else {

		if (raw_key_size != mode->keysize)

			return -EINVAL;

	}

	if (!is_power_of_2(data_unit_size))

		return -EINVAL;

	blk_key->data_unit_size = data_unit_size;

	blk_key->data_unit_size_bits = ilog2(data_unit_size);

	blk_key->size = raw_key_size;

	blk_key->is_hw_wrapped = is_hw_wrapped;

	memcpy(blk_key->raw, raw_key, raw_key_size);

	/*

}

EXPORT_SYMBOL_GPL(blk_crypto_init_key);

/**

 * blk_crypto_start_using_mode() - Start using blk-crypto on a device

 * @crypto_mode: the crypto mode that will be used

 * @data_unit_size: the data unit size that will be used

 * @is_hw_wrapped_key: whether the key will be hardware-wrapped

 * @q: the request queue for the device

 *

 * Upper layers must call this function to ensure that either the hardware

 * supports the needed crypto settings, or the crypto API fallback has

 * transforms for the needed mode allocated and ready to go.

 *

 * Return: 0 on success; -ENOPKG if the hardware doesn't support the crypto

 *	   settings and blk-crypto-fallback is either disabled or the needed

 *	   algorithm is disabled in the crypto API; or another -errno code.

 */

int blk_crypto_start_using_mode(enum blk_crypto_mode_num crypto_mode,

				unsigned int data_unit_size,

				bool is_hw_wrapped_key,

				struct request_queue *q)

{

	if (keyslot_manager_crypto_mode_supported(q->ksm, crypto_mode,

						  data_unit_size,

						  is_hw_wrapped_key))

		return 0;

	if (is_hw_wrapped_key) {

		pr_warn_once("hardware doesn't support wrapped keys\n");

		return -EOPNOTSUPP;

	}

	return blk_crypto_fallback_start_using_mode(crypto_mode);

}

EXPORT_SYMBOL_GPL(blk_crypto_start_using_mode);

/**

 * blk_crypto_evict_key() - Evict a key from any inline encryption hardware

 *			    it may have been programmed into

{

	if (q->ksm &&

	    keyslot_manager_crypto_mode_supported(q->ksm, key->crypto_mode,

						  key->data_unit_size,

						  key->is_hw_wrapped))

						  key->data_unit_size))

		return keyslot_manager_evict_key(q->ksm, key);

	return blk_crypto_fallback_evict_key(key);

struct keyslot_manager {

	unsigned int num_slots;

	struct keyslot_mgmt_ll_ops ksm_ll_ops;

	unsigned int features;

	unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX];

	void *ll_priv_data;

 * @ksm_ll_ops: The struct keyslot_mgmt_ll_ops for the device that this keyslot

 *		manager will use to perform operations like programming and

 *		evicting keys.

 * @features: The supported features as a bitmask of BLK_CRYPTO_FEATURE_* flags.

 *	      Most drivers should set BLK_CRYPTO_FEATURE_STANDARD_KEYS here.

 * @crypto_mode_supported:	Array of size BLK_ENCRYPTION_MODE_MAX of

 *				bitmasks that represents whether a crypto mode

 *				and data unit size are supported. The i'th bit

	struct device *dev,

	unsigned int num_slots,

	const struct keyslot_mgmt_ll_ops *ksm_ll_ops,

	unsigned int features,

	const unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX],

	void *ll_priv_data)

{

	ksm->num_slots = num_slots;

	ksm->ksm_ll_ops = *ksm_ll_ops;

	ksm->features = features;

	memcpy(ksm->crypto_mode_supported, crypto_mode_supported,

	       sizeof(ksm->crypto_mode_supported));

	ksm->ll_priv_data = ll_priv_data;

}

/**

 * keyslot_manager_crypto_mode_supported() - Find out if a crypto_mode /

 *					     data unit size / is_hw_wrapped_key

 *					     combination is supported by a ksm.

 * keyslot_manager_crypto_mode_supported() - Find out if a crypto_mode/data

 *					     unit size combination is supported

 *					     by a ksm.

 * @ksm: The keyslot manager to check

 * @crypto_mode: The crypto mode to check for.

 * @data_unit_size: The data_unit_size for the mode.

 * @is_hw_wrapped_key: Whether a hardware-wrapped key will be used.

 *

 * Calls and returns the result of the crypto_mode_supported function specified

 * by the ksm.

 *

 * Context: Process context.

 * Return: Whether or not this ksm supports the specified crypto settings.

 * Return: Whether or not this ksm supports the specified crypto_mode/

 *	   data_unit_size combo.

 */

bool keyslot_manager_crypto_mode_supported(struct keyslot_manager *ksm,

					   enum blk_crypto_mode_num crypto_mode,

					   unsigned int data_unit_size,

					   bool is_hw_wrapped_key)

					   unsigned int data_unit_size)

{

	if (!ksm)

		return false;

		return false;

	if (WARN_ON(!is_power_of_2(data_unit_size)))

		return false;

	if (is_hw_wrapped_key) {

		if (!(ksm->features & BLK_CRYPTO_FEATURE_WRAPPED_KEYS))

			return false;

	} else {

		if (!(ksm->features & BLK_CRYPTO_FEATURE_STANDARD_KEYS))

			return false;

	}

	return ksm->crypto_mode_supported[crypto_mode] & data_unit_size;

}

 * keyslot_manager_create_passthrough() - Create a passthrough keyslot manager

 * @dev: Device for runtime power management (NULL if none)

 * @ksm_ll_ops: The struct keyslot_mgmt_ll_ops

 * @features: Bitmask of BLK_CRYPTO_FEATURE_* flags

 * @crypto_mode_supported: Bitmasks for supported encryption modes

 * @ll_priv_data: Private data passed as is to the functions in ksm_ll_ops.

 *

struct keyslot_manager *keyslot_manager_create_passthrough(

	struct device *dev,

	const struct keyslot_mgmt_ll_ops *ksm_ll_ops,

	unsigned int features,

	const unsigned int crypto_mode_supported[BLK_ENCRYPTION_MODE_MAX],

	void *ll_priv_data)

{

		return NULL;

	ksm->ksm_ll_ops = *ksm_ll_ops;

	ksm->features = features;

	memcpy(ksm->crypto_mode_supported, crypto_mode_supported,

	       sizeof(ksm->crypto_mode_supported));

	ksm->ll_priv_data = ll_priv_data;

	if (child) {

		unsigned int i;

		parent->features &= child->features;

		for (i = 0; i < ARRAY_SIZE(child->crypto_mode_supported); i++) {

			parent->crypto_mode_supported[i] &=

				child->crypto_mode_supported[i];

		}

	} else {

		parent->features = 0;

		memset(parent->crypto_mode_supported, 0,

		       sizeof(parent->crypto_mode_supported));

	}