Commit e5e0e6be authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'v6.15-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 

Pull crypto updates from Herbert Xu:
 "API:
   - Remove legacy compression interface
   - Improve scatterwalk API
   - Add request chaining to ahash and acomp
   - Add virtual address support to ahash and acomp
   - Add folio support to acomp
   - Remove NULL dst support from acomp

  Algorithms:
   - Library options are fuly hidden (selected by kernel users only)
   - Add Kerberos5 algorithms
   - Add VAES-based ctr(aes) on x86
   - Ensure LZO respects output buffer length on compression
   - Remove obsolete SIMD fallback code path from arm/ghash-ce

  Drivers:
   - Add support for PCI device 0x1134 in ccp
   - Add support for rk3588's standalone TRNG in rockchip
   - Add Inside Secure SafeXcel EIP-93 crypto engine support in eip93
   - Fix bugs in tegra uncovered by multi-threaded self-test
   - Fix corner cases in hisilicon/sec2

  Others:
   - Add SG_MITER_LOCAL to sg miter
   - Convert ubifs, hibernate and xfrm_ipcomp from legacy API to acomp"

* tag 'v6.15-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (187 commits)
  crypto: testmgr - Add multibuffer acomp testing
  crypto: acomp - Fix synchronous acomp chaining fallback
  crypto: testmgr - Add multibuffer hash testing
  crypto: hash - Fix synchronous ahash chaining fallback
  crypto: arm/ghash-ce - Remove SIMD fallback code path
  crypto: essiv - Replace memcpy() + NUL-termination with strscpy()
  crypto: api - Call crypto_alg_put in crypto_unregister_alg
  crypto: scompress - Fix incorrect stream freeing
  crypto: lib/chacha - remove unused arch-specific init support
  crypto: remove obsolete 'comp' compression API
  crypto: compress_null - drop obsolete 'comp' implementation
  crypto: cavium/zip - drop obsolete 'comp' implementation
  crypto: zstd - drop obsolete 'comp' implementation
  crypto: lzo - drop obsolete 'comp' implementation
  crypto: lzo-rle - drop obsolete 'comp' implementation
  crypto: lz4hc - drop obsolete 'comp' implementation
  crypto: lz4 - drop obsolete 'comp' implementation
  crypto: deflate - drop obsolete 'comp' implementation
  crypto: 842 - drop obsolete 'comp' implementation
  crypto: nx - Migrate to scomp API
  ...
parents 7d06015d 99585c21

Documentation/crypto/architecture.rst

+0 −2
Original line number Diff line number Diff line
@@ -196,8 +196,6 @@ the aforementioned cipher types: 


-  CRYPTO_ALG_TYPE_CIPHER Single block cipher



-  CRYPTO_ALG_TYPE_COMPRESS Compression



-  CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data

   (MAC)

Documentation/crypto/index.rst

+1 −0
Original line number Diff line number Diff line
@@ -26,3 +26,4 @@ for cryptographic use cases, as well as programming examples. 
   api-samples

   descore-readme

   device_drivers/index

   krb5

Documentation/crypto/krb5.rst

0 → 100644
+262 −0
Original line number Diff line number Diff line 
.. SPDX-License-Identifier: GPL-2.0



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

Kerberos V Cryptography API

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



.. Contents:



  - Overview.

    - Small Buffer.

  - Encoding Type.

  - Key Derivation.

    - PRF+ Calculation.

    - Kc, Ke And Ki Derivation.

  - Crypto Functions.

    - Preparation Functions.

    - Encryption Mode.

    - Checksum Mode.

  - The krb5enc AEAD algorithm



Overview

========



This API provides Kerberos 5-style cryptography for key derivation, encryption

and checksumming for use in network filesystems and can be used to implement

the low-level crypto that's needed for GSSAPI.



The following crypto types are supported::



	KRB5_ENCTYPE_AES128_CTS_HMAC_SHA1_96

	KRB5_ENCTYPE_AES256_CTS_HMAC_SHA1_96

	KRB5_ENCTYPE_AES128_CTS_HMAC_SHA256_128

	KRB5_ENCTYPE_AES256_CTS_HMAC_SHA384_192

	KRB5_ENCTYPE_CAMELLIA128_CTS_CMAC

	KRB5_ENCTYPE_CAMELLIA256_CTS_CMAC



	KRB5_CKSUMTYPE_HMAC_SHA1_96_AES128

	KRB5_CKSUMTYPE_HMAC_SHA1_96_AES256

	KRB5_CKSUMTYPE_CMAC_CAMELLIA128

	KRB5_CKSUMTYPE_CMAC_CAMELLIA256

	KRB5_CKSUMTYPE_HMAC_SHA256_128_AES128

	KRB5_CKSUMTYPE_HMAC_SHA384_192_AES256



The API can be included by::



	#include <crypto/krb5.h>



Small Buffer

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



To pass small pieces of data about, such as keys, a buffer structure is

defined, giving a pointer to the data and the size of that data::



	struct krb5_buffer {

		unsigned int	len;

		void		*data;

	};



Encoding Type

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



The encoding type is defined by the following structure::



	struct krb5_enctype {

		int		etype;

		int		ctype;

		const char	*name;

		u16		key_bytes;

		u16		key_len;

		u16		Kc_len;

		u16		Ke_len;

		u16		Ki_len;

		u16		prf_len;

		u16		block_len;

		u16		conf_len;

		u16		cksum_len;

		...

	};



The fields of interest to the user of the API are as follows:



  * ``etype`` and ``ctype`` indicate the protocol number for this encoding

    type for encryption and checksumming respectively.  They hold

    ``KRB5_ENCTYPE_*`` and ``KRB5_CKSUMTYPE_*`` constants.



  * ``name`` is the formal name of the encoding.



  * ``key_len`` and ``key_bytes`` are the input key length and the derived key

    length.  (I think they only differ for DES, which isn't supported here).



  * ``Kc_len``, ``Ke_len`` and ``Ki_len`` are the sizes of the derived Kc, Ke

    and Ki keys.  Kc is used for in checksum mode; Ke and Ki are used in

    encryption mode.



  * ``prf_len`` is the size of the result from the PRF+ function calculation.



  * ``block_len``, ``conf_len`` and ``cksum_len`` are the encryption block

    length, confounder length and checksum length respectively.  All three are

    used in encryption mode, but only the checksum length is used in checksum

    mode.



The encoding type is looked up by number using the following function::



	const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);



Key Derivation

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



Once the application has selected an encryption type, the keys that will be

used to do the actual crypto can be derived from the transport key.



PRF+ Calculation

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



To aid in key derivation, a function to calculate the Kerberos GSSAPI

mechanism's PRF+ is provided::



	int crypto_krb5_calc_PRFplus(const struct krb5_enctype *krb5,

				     const struct krb5_buffer *K,

				     unsigned int L,

				     const struct krb5_buffer *S,

				     struct krb5_buffer *result,

				     gfp_t gfp);



This can be used to derive the transport key from a source key plus additional

data to limit its use.



Crypto Functions

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



Once the keys have been derived, crypto can be performed on the data.  The

caller must leave gaps in the buffer for the storage of the confounder (if

needed) and the checksum when preparing a message for transmission.  An enum

and a pair of functions are provided to aid in this::



	enum krb5_crypto_mode {

		KRB5_CHECKSUM_MODE,

		KRB5_ENCRYPT_MODE,

	};



	size_t crypto_krb5_how_much_buffer(const struct krb5_enctype *krb5,

					   enum krb5_crypto_mode mode,

					   size_t data_size, size_t *_offset);



	size_t crypto_krb5_how_much_data(const struct krb5_enctype *krb5,

					 enum krb5_crypto_mode mode,

					 size_t *_buffer_size, size_t *_offset);



All these functions take the encoding type and an indication the mode of crypto

(checksum-only or full encryption).



The first function returns how big the buffer will need to be to house a given

amount of data; the second function returns how much data will fit in a buffer

of a particular size, and adjusts down the size of the required buffer

accordingly.  In both cases, the offset of the data within the buffer is also

returned.



When a message has been received, the location and size of the data with the

message can be determined by calling::



	void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,

					   enum krb5_crypto_mode mode,

					   size_t *_offset, size_t *_len);



The caller provides the offset and length of the message to the function, which

then alters those values to indicate the region containing the data (plus any

padding).  It is up to the caller to determine how much padding there is.



Preparation Functions

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



Two functions are provided to allocated and prepare a crypto object for use by

the action functions::



	struct crypto_aead *

	crypto_krb5_prepare_encryption(const struct krb5_enctype *krb5,

				       const struct krb5_buffer *TK,

				       u32 usage, gfp_t gfp);

	struct crypto_shash *

	crypto_krb5_prepare_checksum(const struct krb5_enctype *krb5,

				     const struct krb5_buffer *TK,

				     u32 usage, gfp_t gfp);



Both of these functions take the encoding type, the transport key and the usage

value used to derive the appropriate subkey(s).  They create an appropriate

crypto object, an AEAD template for encryption and a synchronous hash for

checksumming, set the key(s) on it and configure it.  The caller is expected to

pass these handles to the action functions below.



Encryption Mode

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



A pair of functions are provided to encrypt and decrypt a message::



	ssize_t crypto_krb5_encrypt(const struct krb5_enctype *krb5,

				    struct crypto_aead *aead,

				    struct scatterlist *sg, unsigned int nr_sg,

				    size_t sg_len,

				    size_t data_offset, size_t data_len,

				    bool preconfounded);

	int crypto_krb5_decrypt(const struct krb5_enctype *krb5,

				struct crypto_aead *aead,

				struct scatterlist *sg, unsigned int nr_sg,

				size_t *_offset, size_t *_len);



In both cases, the input and output buffers are indicated by the same

scatterlist.



For the encryption function, the output buffer may be larger than is needed

(the amount of output generated is returned) and the location and size of the

data are indicated (which must match the encoding).  If no confounder is set,

the function will insert one.



For the decryption function, the offset and length of the message in buffer are

supplied and these are shrunk to fit the data.  The decryption function will

verify any checksums within the message and give an error if they don't match.



Checksum Mode

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



A pair of function are provided to generate the checksum on a message and to

verify that checksum::



	ssize_t crypto_krb5_get_mic(const struct krb5_enctype *krb5,

				    struct crypto_shash *shash,

				    const struct krb5_buffer *metadata,

				    struct scatterlist *sg, unsigned int nr_sg,

				    size_t sg_len,

				    size_t data_offset, size_t data_len);

	int crypto_krb5_verify_mic(const struct krb5_enctype *krb5,

				   struct crypto_shash *shash,

				   const struct krb5_buffer *metadata,

				   struct scatterlist *sg, unsigned int nr_sg,

				   size_t *_offset, size_t *_len);



In both cases, the input and output buffers are indicated by the same

scatterlist.  Additional metadata can be passed in which will get added to the

hash before the data.



For the get_mic function, the output buffer may be larger than is needed (the

amount of output generated is returned) and the location and size of the data

are indicated (which must match the encoding).



For the verification function, the offset and length of the message in buffer

are supplied and these are shrunk to fit the data.  An error will be returned

if the checksums don't match.



The krb5enc AEAD algorithm

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



A template AEAD crypto algorithm, called "krb5enc", is provided that hashes the

plaintext before encrypting it (the reverse of authenc).  The handle returned

by ``crypto_krb5_prepare_encryption()`` may be one of these, but there's no

requirement for the user of this API to interact with it directly.



For reference, its key format begins with a BE32 of the format number.  Only

format 1 is provided and that continues with a BE32 of the Ke key length

followed by a BE32 of the Ki key length, followed by the bytes from the Ke key

and then the Ki key.



Using specifically ordered words means that the static test data doesn't

require byteswapping.

Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml

0 → 100644
+144 −0
Original line number Diff line number Diff line 
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

%YAML 1.2

---

$id: http://devicetree.org/schemas/crypto/fsl,sec2.0.yaml#

$schema: http://devicetree.org/meta-schemas/core.yaml#



title: Freescale SoC SEC Security Engines versions 1.x-2.x-3.x



maintainers:

  - J. Neuschäfer <j.ne@posteo.net>



properties:

  compatible:

    description:

      Should contain entries for this and backward compatible SEC versions,

      high to low. Warning - SEC1 and SEC2 are mutually exclusive.

    oneOf:

      - items:

          - const: fsl,sec3.3

          - const: fsl,sec3.1

          - const: fsl,sec3.0

          - const: fsl,sec2.4

          - const: fsl,sec2.2

          - const: fsl,sec2.1

          - const: fsl,sec2.0

      - items:

          - const: fsl,sec3.1

          - const: fsl,sec3.0

          - const: fsl,sec2.4

          - const: fsl,sec2.2

          - const: fsl,sec2.1

          - const: fsl,sec2.0

      - items:

          - const: fsl,sec3.0

          - const: fsl,sec2.4

          - const: fsl,sec2.2

          - const: fsl,sec2.1

          - const: fsl,sec2.0

      - items:

          - const: fsl,sec2.4

          - const: fsl,sec2.2

          - const: fsl,sec2.1

          - const: fsl,sec2.0

      - items:

          - const: fsl,sec2.2

          - const: fsl,sec2.1

          - const: fsl,sec2.0

      - items:

          - const: fsl,sec2.1

          - const: fsl,sec2.0

      - items:

          - const: fsl,sec2.0

      - items:

          - const: fsl,sec1.2

          - const: fsl,sec1.0

      - items:

          - const: fsl,sec1.0



  reg:

    maxItems: 1



  interrupts:

    maxItems: 1



  fsl,num-channels:

    $ref: /schemas/types.yaml#/definitions/uint32

    enum: [ 1, 4 ]

    description: An integer representing the number of channels available.



  fsl,channel-fifo-len:

    $ref: /schemas/types.yaml#/definitions/uint32

    maximum: 100

    description:

      An integer representing the number of descriptor pointers each channel

      fetch fifo can hold.



  fsl,exec-units-mask:

    $ref: /schemas/types.yaml#/definitions/uint32

    maximum: 0xfff

    description: |

      The bitmask representing what execution units (EUs) are available.

      EU information should be encoded following the SEC's Descriptor Header

      Dword EU_SEL0 field documentation, i.e. as follows:



        bit 0  = reserved - should be 0

        bit 1  = set if SEC has the ARC4 EU (AFEU)

        bit 2  = set if SEC has the DES/3DES EU (DEU)

        bit 3  = set if SEC has the message digest EU (MDEU/MDEU-A)

        bit 4  = set if SEC has the random number generator EU (RNG)

        bit 5  = set if SEC has the public key EU (PKEU)

        bit 6  = set if SEC has the AES EU (AESU)

        bit 7  = set if SEC has the Kasumi EU (KEU)

        bit 8  = set if SEC has the CRC EU (CRCU)

        bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B)



      remaining bits are reserved for future SEC EUs.



  fsl,descriptor-types-mask:

    $ref: /schemas/types.yaml#/definitions/uint32

    description: |

      The bitmask representing what descriptors are available. Descriptor type

      information should be encoded following the SEC's Descriptor Header Dword

      DESC_TYPE field documentation, i.e. as follows:



        bit 0  = SEC supports descriptor type aesu_ctr_nonsnoop

        bit 1  = SEC supports descriptor type ipsec_esp

        bit 2  = SEC supports descriptor type common_nonsnoop

        bit 3  = SEC supports descriptor type 802.11i AES ccmp

        bit 4  = SEC supports descriptor type hmac_snoop_no_afeu

        bit 5  = SEC supports descriptor type srtp

        bit 6  = SEC supports descriptor type non_hmac_snoop_no_afeu

        bit 7  = SEC supports descriptor type pkeu_assemble

        bit 8  = SEC supports descriptor type aesu_key_expand_output

        bit 9  = SEC supports descriptor type pkeu_ptmul

        bit 10 = SEC supports descriptor type common_nonsnoop_afeu

        bit 11 = SEC supports descriptor type pkeu_ptadd_dbl



      ..and so on and so forth.



required:

  - compatible

  - reg

  - fsl,num-channels

  - fsl,channel-fifo-len

  - fsl,exec-units-mask

  - fsl,descriptor-types-mask



unevaluatedProperties: false



examples:

  - |

    /* MPC8548E */

    crypto@30000 {

        compatible = "fsl,sec2.1", "fsl,sec2.0";

        reg = <0x30000 0x10000>;

        interrupts = <29 2>;

        interrupt-parent = <&mpic>;

        fsl,num-channels = <4>;

        fsl,channel-fifo-len = <24>;

        fsl,exec-units-mask = <0xfe>;

        fsl,descriptor-types-mask = <0x12b0ebf>;

    };



...

Documentation/devicetree/bindings/crypto/fsl-sec2.txt

deleted100644 → 0
+0 −65
Original line number Diff line number Diff line 
Freescale SoC SEC Security Engines versions 1.x-2.x-3.x



Required properties:



- compatible : Should contain entries for this and backward compatible

  SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" (SEC2/3)

                             e.g., "fsl,sec1.2", "fsl,sec1.0" (SEC1)

    warning: SEC1 and SEC2 are mutually exclusive

- reg : Offset and length of the register set for the device

- interrupts : the SEC's interrupt number

- fsl,num-channels : An integer representing the number of channels

  available.

- fsl,channel-fifo-len : An integer representing the number of

  descriptor pointers each channel fetch fifo can hold.

- fsl,exec-units-mask : The bitmask representing what execution units

  (EUs) are available. It's a single 32-bit cell. EU information

  should be encoded following the SEC's Descriptor Header Dword

  EU_SEL0 field documentation, i.e. as follows:



	bit 0  = reserved - should be 0

	bit 1  = set if SEC has the ARC4 EU (AFEU)

	bit 2  = set if SEC has the DES/3DES EU (DEU)

	bit 3  = set if SEC has the message digest EU (MDEU/MDEU-A)

	bit 4  = set if SEC has the random number generator EU (RNG)

	bit 5  = set if SEC has the public key EU (PKEU)

	bit 6  = set if SEC has the AES EU (AESU)

	bit 7  = set if SEC has the Kasumi EU (KEU)

	bit 8  = set if SEC has the CRC EU (CRCU)

	bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B)



remaining bits are reserved for future SEC EUs.



- fsl,descriptor-types-mask : The bitmask representing what descriptors

  are available. It's a single 32-bit cell. Descriptor type information

  should be encoded following the SEC's Descriptor Header Dword DESC_TYPE

  field documentation, i.e. as follows:



	bit 0  = set if SEC supports the aesu_ctr_nonsnoop desc. type

	bit 1  = set if SEC supports the ipsec_esp descriptor type

	bit 2  = set if SEC supports the common_nonsnoop desc. type

	bit 3  = set if SEC supports the 802.11i AES ccmp desc. type

	bit 4  = set if SEC supports the hmac_snoop_no_afeu desc. type

	bit 5  = set if SEC supports the srtp descriptor type

	bit 6  = set if SEC supports the non_hmac_snoop_no_afeu desc.type

	bit 7  = set if SEC supports the pkeu_assemble descriptor type

	bit 8  = set if SEC supports the aesu_key_expand_output desc.type

	bit 9  = set if SEC supports the pkeu_ptmul descriptor type

	bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type

	bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type



  ..and so on and so forth.



Example:



	/* MPC8548E */

	crypto@30000 {

		compatible = "fsl,sec2.1", "fsl,sec2.0";

		reg = <0x30000 0x10000>;

		interrupts = <29 2>;

		interrupt-parent = <&mpic>;

		fsl,num-channels = <4>;

		fsl,channel-fifo-len = <24>;

		fsl,exec-units-mask = <0xfe>;

		fsl,descriptor-types-mask = <0x12b0ebf>;

	};