[PATCH v3 1/4] dt-bindings: crypto: add ARTPEC crypto

Document the device tree bindings for the ARTPEC crypto accelerator on ARTPEC-6 and ARTPEC-7 SoCs. Signed-off-by: Lars Persson --- .../devicetree/bindings/crypto/artpec6-crypto.txt| 16 1 file changed, 16 insertions(+) create mode 100644

[PATCH v3 3/4] crypto: axis: add ARTPEC-6/7 crypto accelerator driver

This is an asynchronous crypto API driver for the accelerator present in the ARTPEC-6 and -7 SoCs from Axis Communications AB. The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash standards. Signed-off-by: Lars Persson --- drivers/crypto/Kconfig |

[PATCH v3 2/4] crypto: add crypto_(un)register_ahashes()

From: Rabin Vincent There are already helpers to (un)register multiple normal and AEAD algos. Add one for ahashes too. Signed-off-by: Lars Persson Signed-off-by: Rabin Vincent --- crypto/ahash.c | 29

[PATCH v3 0/4] crypto: add driver for Axis ARTPEC crypto accelerator

This series adds a driver for the crypto accelerator in the ARTPEC series of SoCs from Axis Communications AB. Changelog v3: - The patch author added his Signed-off-by on patch 2. Changelog v2: - Use xts_check_key() for xts keys. - Use CRYPTO_ALG_TYPE_SKCIPHER instead of

[PATCH v3 4/4] MAINTAINERS: Add ARTPEC crypto maintainer

Assign the Axis kernel team as maintainer for crypto drivers under drivers/crypto/axis. Signed-off-by: Lars Persson --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index d5b6c71e783e..72186cf9820d 100644 --- a/MAINTAINERS +++

[PATCH v4 0/7] Appended signatures support for IMA appraisal

Hello, This version implements an approach suggested by Mimi Zohar, which is that if the modsig is valid, ima_appraise_measurement will now copy the hash calculated by the verification process into the iint cache. This ensures that the hash will appear in the measurement list and used to extend

[PATCH v4 1/7] integrity: Introduce struct evm_xattr

Even though struct evm_ima_xattr_data includes a fixed-size array to hold a SHA1 digest, most of the code ignores the array and uses the struct to mean "type indicator followed by data of unspecified size" and tracks the real size of what the struct represents in a separate length variable. The

[PATCH v4 5/7] integrity: Select CONFIG_KEYS instead of depending on it

This avoids a dependency cycle in CONFIG_IMA_APPRAISE_MODSIG (introduced by a later patch in this series): it will select CONFIG_MODULE_SIG_FORMAT which in turn selects CONFIG_KEYS. Kconfig then complains that CONFIG_INTEGRITY_SIGNATURE depends on CONFIG_KEYS. Signed-off-by: Thiago Jung Bauermann

Re: [PATCH v6 2/3] ARM: i.MX25: add RNGB node to dtsi

On Sun, Jul 23, 2017 at 07:49:05PM +0200, Martin Kaiser wrote: > From: Steffen Trumtrar > > Add a devicetree entry for the Random Number Generator Version B (RNGB). > The driver for RNGC supports version B as well. > > Signed-off-by: Steffen Trumtrar

Re: [PATCH 0/4] crypto: caam - add Job Ring support for DPAA2 parts

On Tue, Jul 18, 2017 at 06:30:46PM +0300, Horia Geantă wrote: > This patch set adds support for CAAM's legacy Job Ring backend / interface > on platforms having DPAA2 (Datapath Acceleration Architecture v2), like > LS1088A or LS2088A. > > I would like to get the DT patches through the crypto list

[PATCH v4 7/7] ima: Support module-style appended signatures for appraisal

This patch introduces the modsig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule: appraise func=KEXEC_KERNEL_CHECK appraise_type=modsig|imasig With this rule, IMA will accept

[PATCH v4 6/7] ima: Store measurement after appraisal

When module-style signatures appended at the end of files are supported for IMA appraisal, the code will fallback to the xattr signature if the appended one fails to verify. The problem is that we don't know whether we need to fallback to the xattr signature until the appraise step, and by then

[PATCH v4 4/7] integrity: Introduce integrity_keyring_from_id

IMA will need to obtain the keyring used to verify file signatures so that it can verify the module-style signature appended to files. Signed-off-by: Thiago Jung Bauermann --- security/integrity/digsig.c| 28 +++-

[PATCH v4 2/7] MODSIGN: Export module signature definitions

IMA will use the module_signature format for append signatures, so export the relevant definitions and factor out the code which verifies that the appended signature trailer is valid. Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it and be able to use

[PATCH v4 3/7] PKCS#7: Introduce pkcs7_get_message_sig and verify_pkcs7_message_sig

IMA will need to access the digest used in the signature so that it can verify files containing module-style appended signatures. For this purpose, add function pkcs7_get_message_sig. It will also need to verify an already parsed PKCS#7 message. For this purpose, add function

Re: [PATCH v6 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

On 03/08/17 21:30, Logan Gunthorpe wrote: > Add a check to ensure iowrite64 is only used if it is atomic. > > It was decided in [1] that the tilcdc driver should not be using an > atomic operation (so it was left out of this patchset). However, it turns > out that through the drm code, a

Re: [PATCH v6 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

On 04/08/17 07:03 AM, Tomi Valkeinen wrote: > I haven't really followed the discussion on this, but if the tilcdc's > use of iowrite64 causes (real) problems/complications elsewhere, I think > we could drop it. Well, that's up to you. The patch I submitted should still be correct though, and if