* [PATCH v3 0/4] crypto: Key Derivation Function (SP800-108)
From: Stephan Mueller @ 2016-07-12 9:06 UTC (permalink / raw)
To: Mat Martineau; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <4161793.TTVXSVQtZL@positron.chronox.de>
Hi,
this patch set implements all three key derivation functions defined in
SP800-108.
The implementation is provided as a template for random number generators,
since a KDF can be considered a form of deterministic RNG where the key
material is used as a seed.
With the KDF implemented as a template, all types of keyed hashes can be
utilized, including HMAC and CMAC. The testmgr tests are derived from
publicly available test vectors from NIST.
The KDF are all tested with a complete round of CAVS testing on 32 and 64 bit.
The patch set introduces an extension to the kernel crypto API in the first
patch by adding a template handling for random number generators based on the
same logic as for keyed hashes.
Changes v3:
* port testmgr patch to current cryptodev-2.6 tree
* add non-keyed KDF references to testmgr.c
Changes v2:
* port to 4.7-rc1
Stephan Mueller (4):
crypto: add template handling for RNGs
crypto: kdf - add known answer tests
crypto: kdf - SP800-108 Key Derivation Function
crypto: kdf - enable compilation
crypto/Kconfig | 7 +
crypto/Makefile | 1 +
crypto/kdf.c | 514 +++++++++++++++++++++++++++++++++++++++++++++++++++
crypto/rng.c | 31 ++++
crypto/testmgr.c | 226 ++++++++++++++++++++++
crypto/testmgr.h | 110 +++++++++++
include/crypto/rng.h | 39 ++++
7 files changed, 928 insertions(+)
create mode 100644 crypto/kdf.c
--
2.7.4
^ permalink raw reply
* [RFC PATCH] KEYS: add SP800-56A KDF support for DH
From: Stephan Mueller @ 2016-07-12 9:06 UTC (permalink / raw)
To: Mat Martineau, David Howells; +Cc: keyrings, linux-crypto
Hi Mat, David,
This patch is based on the cryptodev-2.6 tree with the patch
4693fc734d675c5518ea9bd4c9623db45bc37402 ("KEYS: Add placeholder
for KDF usage with DH") from Linus' tree added on top.
I am aware of the fact that the compat code is not present. This
patch is intended for review to verify that the user space
interface follows the general approach for the keys subsystem.
The patch to add KDF to the kernel crypto API will be appended to
this patch.
The patch for the keyutils user space extension will also be added.
Ciao
Stephan
---8<---
SP800-56A define the use of DH with key derivation function based on a
counter. The input to the KDF is defined as (DH shared secret || other
information). The value for the "other information" is to be provided by
the caller.
The KDF is provided by the kernel crypto API. The SP800-56A KDF is equal
to the SP800-108 counter KDF. However, the caller is allowed to specify
the KDF type that he wants to use to derive the key material allowing
the use of the other KDFs provided with the kernel crypto API.
As the KDF implements the proper truncation of the DH shared secret to
the requested size, this patch fills the caller buffer up to its size.
The patch is tested with a new test added to the keyutils user space
code which uses a CAVS test vector testing the compliance with
SP800-56A.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
include/uapi/linux/keyctl.h | 10 +++++
security/keys/Kconfig | 1 +
security/keys/dh.c | 98 ++++++++++++++++++++++++++++++++++++++++-----
security/keys/internal.h | 5 ++-
security/keys/keyctl.c | 2 +-
5 files changed, 103 insertions(+), 13 deletions(-)
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 86eddd6..cc4ce7c 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -68,4 +68,14 @@ struct keyctl_dh_params {
__s32 base;
};
+struct keyctl_kdf_params {
+#define KEYCTL_KDF_MAX_OUTPUTLEN 1024 /* max length of KDF output */
+#define KEYCTL_KDF_MAX_STRING_LEN 64 /* maximum length of strings */
+ char *kdfname;
+ __u32 kdfnamelen;
+ char *otherinfo;
+ __u32 otherinfolen;
+ __u32 flags;
+};
+
#endif /* _LINUX_KEYCTL_H */
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index f826e87..56491fe 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -90,6 +90,7 @@ config KEY_DH_OPERATIONS
bool "Diffie-Hellman operations on retained keys"
depends on KEYS
select MPILIB
+ select CRYPTO_KDF
help
This option provides support for calculating Diffie-Hellman
public keys and shared secrets using values stored as keys
diff --git a/security/keys/dh.c b/security/keys/dh.c
index 531ed2e..4c93969 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -77,14 +77,74 @@ error:
return ret;
}
+static int keyctl_dh_compute_kdf(struct keyctl_kdf_params *kdfcopy,
+ char __user *buffer, size_t buflen,
+ uint8_t *kbuf, size_t resultlen)
+{
+ char kdfname[CRYPTO_MAX_ALG_NAME] = { 0 };
+ struct crypto_rng *tfm;
+ uint8_t *outbuf = NULL;
+ int ret;
+
+ BUILD_BUG_ON(CRYPTO_MAX_ALG_NAME != KEYCTL_KDF_MAX_STRING_LEN);
+ if (!kdfcopy->kdfnamelen)
+ return -EFAULT;
+ if (copy_from_user(&kdfname, kdfcopy->kdfname,
+ kdfcopy->kdfnamelen) != 0)
+ return -EFAULT;
+
+ /*
+ * Concatenate otherinfo past DH shared secret -- the
+ * input to the KDF is (DH shared secret || otherinfo)
+ */
+ if (kdfcopy->otherinfo &&
+ copy_from_user(kbuf + resultlen, kdfcopy->otherinfo,
+ kdfcopy->otherinfolen)
+ != 0)
+ return -EFAULT;
+
+ tfm = crypto_alloc_rng(kdfname, 0, 0);
+ if (IS_ERR(tfm))
+ return PTR_ERR(tfm);
+
+#if 0
+ /* we do not support HMAC currently */
+ ret = crypto_rng_reset(tfm, xx, xxlen);
+ if (ret) {
+ crypto_free_rng(tfm);
+ goto error5;
+ }
+#endif
+
+ outbuf = kmalloc(buflen, GFP_KERNEL);
+ if (!outbuf) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = crypto_rng_generate(tfm, kbuf, resultlen + kdfcopy->otherinfolen,
+ outbuf, buflen);
+ if (ret)
+ goto err;
+
+ ret = buflen;
+ if (copy_to_user(buffer, outbuf, buflen) != 0)
+ ret = -EFAULT;
+
+err:
+ kzfree(outbuf);
+ crypto_free_rng(tfm);
+ return ret;
+}
long keyctl_dh_compute(struct keyctl_dh_params __user *params,
char __user *buffer, size_t buflen,
- void __user *reserved)
+ struct keyctl_kdf_params __user *kdf)
{
long ret;
MPI base, private, prime, result;
unsigned nbytes;
struct keyctl_dh_params pcopy;
+ struct keyctl_kdf_params kdfcopy;
uint8_t *kbuf;
ssize_t keylen;
size_t resultlen;
@@ -98,12 +158,24 @@ long keyctl_dh_compute(struct keyctl_dh_params __user *params,
goto out;
}
- if (reserved) {
- ret = -EINVAL;
- goto out;
+ if (kdf) {
+ if (copy_from_user(&kdfcopy, kdf, sizeof(kdfcopy)) != 0) {
+ ret = -EFAULT;
+ goto out;
+ }
+ if (buflen > KEYCTL_KDF_MAX_OUTPUTLEN ||
+ kdfcopy.otherinfolen > KEYCTL_KDF_MAX_STRING_LEN ||
+ kdfcopy.kdfnamelen > KEYCTL_KDF_MAX_STRING_LEN) {
+ ret = -EMSGSIZE;
+ goto out;
+ }
}
- keylen = mpi_from_key(pcopy.prime, buflen, &prime);
+ /*
+ * If the caller requests postprocessing with a KDF, allow an
+ * arbitrary output buffer size since the KDF ensures proper truncation.
+ */
+ keylen = mpi_from_key(pcopy.prime, kdf ? SIZE_MAX : buflen, &prime);
if (keylen < 0 || !prime) {
/* buflen == 0 may be used to query the required buffer size,
* which is the prime key length.
@@ -133,7 +205,8 @@ long keyctl_dh_compute(struct keyctl_dh_params __user *params,
goto error3;
}
- kbuf = kmalloc(resultlen, GFP_KERNEL);
+ kbuf = kmalloc(kdf ? (resultlen + kdfcopy.otherinfolen) : resultlen,
+ GFP_KERNEL);
if (!kbuf) {
ret = -ENOMEM;
goto error4;
@@ -147,12 +220,17 @@ long keyctl_dh_compute(struct keyctl_dh_params __user *params,
if (ret != 0)
goto error5;
- ret = nbytes;
- if (copy_to_user(buffer, kbuf, nbytes) != 0)
- ret = -EFAULT;
+ if (kdf) {
+ ret = keyctl_dh_compute_kdf(&kdfcopy, buffer, buflen,
+ kbuf, resultlen);
+ } else {
+ ret = nbytes;
+ if (copy_to_user(buffer, kbuf, nbytes) != 0)
+ ret = -EFAULT;
+ }
error5:
- kfree(kbuf);
+ kzfree(kbuf);
error4:
mpi_free(result);
error3:
diff --git a/security/keys/internal.h b/security/keys/internal.h
index a705a7d..35a8d11 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -259,12 +259,13 @@ static inline long keyctl_get_persistent(uid_t uid, key_serial_t destring)
#endif
#ifdef CONFIG_KEY_DH_OPERATIONS
+#include <crypto/rng.h>
extern long keyctl_dh_compute(struct keyctl_dh_params __user *, char __user *,
- size_t, void __user *);
+ size_t, struct keyctl_kdf_params __user *);
#else
static inline long keyctl_dh_compute(struct keyctl_dh_params __user *params,
char __user *buffer, size_t buflen,
- void __user *reserved)
+ struct keyctl_kdf_params __user *kdf)
{
return -EOPNOTSUPP;
}
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index d580ad0..b106898 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1689,7 +1689,7 @@ SYSCALL_DEFINE5(keyctl, int, option, unsigned long, arg2, unsigned long, arg3,
case KEYCTL_DH_COMPUTE:
return keyctl_dh_compute((struct keyctl_dh_params __user *) arg2,
(char __user *) arg3, (size_t) arg4,
- (void __user *) arg5);
+ (struct keyctl_kdf_params __user *) arg5);
default:
return -EOPNOTSUPP;
--
2.7.2
^ permalink raw reply related
* RE: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS
From: David Laight @ 2016-07-12 16:19 UTC (permalink / raw)
To: 'Paulo Flabiano Smorigo', linux-kernel@vger.kernel.org
Cc: Leonidas S. Barbosa, Herbert Xu, Paul Mackerras,
open list:IBM Power VMX Cryptographic instructions,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, David S. Miller
In-Reply-To: <1468264060-22769-1-git-send-email-pfsmorigo@linux.vnet.ibm.com>
From: Paulo Flabiano Smorigo
> Sent: 11 July 2016 20:08
>
> This patch add XTS subroutines using VMX-crypto driver.
>
> It gives a boost of 20 times using XTS.
>
> These code has been adopted from OpenSSL project in collaboration
> with the original author (Andy Polyakov <appro@openssl.org>).
Yep, typical openssl code. 1000+ lines of uncommented impenetrable assembler.
There is 0 chance of anyone ever checking this does what it should.
David
^ permalink raw reply
* Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS
From: Stewart Smith @ 2016-07-13 3:05 UTC (permalink / raw)
To: Stephen Rothwell, Paulo Flabiano Smorigo
Cc: Leonidas S. Barbosa, Herbert Xu, linux-kernel, Paul Mackerras,
open list:IBM Power VMX Cryptographic instructions,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, David S. Miller
In-Reply-To: <20160712093705.6f0fde7a@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> On Mon, 11 Jul 2016 16:07:39 -0300 Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> wrote:
>>
>> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
>> index 2280539..813ffcc 100644
>> --- a/drivers/crypto/vmx/aesp8-ppc.pl
>> +++ b/drivers/crypto/vmx/aesp8-ppc.pl
>> @@ -1,4 +1,11 @@
>> -#!/usr/bin/env perl
>> +#! /usr/bin/env perl
>> +# Copyright 2014-2016 The OpenSSL Project Authors. All Rights Reserved.
>> +#
>> +# Licensed under the OpenSSL license (the "License"). You may not use
>> +# this file except in compliance with the License. You can obtain a copy
>> +# in the file LICENSE in the source distribution or at
>> +# https://www.openssl.org/source/license.html
>
> So, I assume that this license is compatible with the GPLv2?
https://people.gnome.org/~markmc/openssl-and-the-gpl.html has an
explanation and points to:
https://www.openssl.org/docs/faq.html#LEGAL2
which makes it anything but clearer.
it appears the answer is "probably not, unless you have an explicit
exemption in your license"
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* [PATCH 2/2] Automatically load the vmx_crypto module if supported.
From: alastair @ 2016-07-13 5:47 UTC (permalink / raw)
To: mpe
Cc: benh, paulus, herbert, davem, linuxppc-dev, linux-crypto,
linux-kernel, Alastair D'Silva
In-Reply-To: <1468388840-12068-1-git-send-email-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
to automatically load the vmx_crypto module if the CPU supports
it.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
drivers/crypto/vmx/Kconfig | 2 +-
drivers/crypto/vmx/vmx.c | 6 ++----
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/vmx/Kconfig b/drivers/crypto/vmx/Kconfig
index 89d8208..a83ead1 100644
--- a/drivers/crypto/vmx/Kconfig
+++ b/drivers/crypto/vmx/Kconfig
@@ -1,7 +1,7 @@
config CRYPTO_DEV_VMX_ENCRYPT
tristate "Encryption acceleration support on P8 CPU"
depends on CRYPTO_DEV_VMX
- default y
+ default m
help
Support for VMX cryptographic acceleration instructions on Power8 CPU.
This module supports acceleration for AES and GHASH in hardware. If you
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index e163d57..5a40f2f 100644
--- a/drivers/crypto/vmx/vmx.c
+++ b/drivers/crypto/vmx/vmx.c
@@ -23,6 +23,7 @@
#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/err.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <asm/cputable.h>
#include <crypto/internal/hash.h>
@@ -43,9 +44,6 @@ int __init p8_init(void)
int ret = 0;
struct crypto_alg **alg_it;
- if (!(cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_VEC_CRYPTO))
- return -ENODEV;
-
for (alg_it = algs; *alg_it; alg_it++) {
ret = crypto_register_alg(*alg_it);
printk(KERN_INFO "crypto_register_alg '%s' = %d\n",
@@ -78,7 +76,7 @@ void __exit p8_exit(void)
crypto_unregister_shash(&p8_ghash_alg);
}
-module_init(p8_init);
+module_cpu_feature_match(PPC_MODULE_FEATURE_VEC_CRYPTO, p8_init);
module_exit(p8_exit);
MODULE_AUTHOR("Marcelo Cerri<mhcerri@br.ibm.com>");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] Allow drivers to be autoloaded.
From: alastair @ 2016-07-13 5:47 UTC (permalink / raw)
To: mpe
Cc: benh, paulus, herbert, davem, linuxppc-dev, linux-crypto,
linux-kernel, Alastair D'Silva
In-Reply-To: <1468388840-12068-1-git-send-email-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This patch provides the necessary infrastructure to allow drivers
to be automatically loaded via UDEV. It implements the minimum
required to be able to use module_cpu_feature_match to trigger
the GENERIC_CPU_AUTOPROBE mechanisms.
The features exposed are a mirror of the cpu_user_features
(converted to an offset from a mask). This decision was made to
ensure that the behavior between features for module loading and
userspace are consistent.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/cpufeature.h | 68 +++++++++++++++++++++++++++++++++++
2 files changed, 69 insertions(+)
create mode 100644 arch/powerpc/include/asm/cpufeature.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0a9d439..a6e49db 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -164,6 +164,7 @@ config PPC
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
+ select GENERIC_CPU_AUTOPROBE
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h
new file mode 100644
index 0000000..6d52527
--- /dev/null
+++ b/arch/powerpc/include/asm/cpufeature.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright 2016 Alastair D'Silva, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_CPUFEATURE_H
+
+#include <asm/cputable.h>
+
+/* Keep these in step with powerpc/include/asm/cputable.h */
+#define MAX_CPU_FEATURES (2 * 32)
+
+#define PPC_MODULE_FEATURE_32 (ilog2(PPC_FEATURE_32))
+#define PPC_MODULE_FEATURE_64 (ilog2(PPC_FEATURE_64))
+#define PPC_MODULE_FEATURE_601_INSTR (ilog2(PPC_FEATURE_601_INSTR))
+#define PPC_MODULE_FEATURE_HAS_ALTIVEC (ilog2(PPC_FEATURE_HAS_ALTIVEC))
+#define PPC_MODULE_FEATURE_HAS_FPU (ilog2(PPC_FEATURE_HAS_FPU))
+#define PPC_MODULE_FEATURE_HAS_MMU (ilog2(PPC_FEATURE_HAS_MMU))
+#define PPC_MODULE_FEATURE_HAS_4xxMAC (ilog2(PPC_FEATURE_HAS_4xxMAC))
+#define PPC_MODULE_FEATURE_UNIFIED_CACHE ilog2(PPC_FEATURE_UNIFIED_CACHE))
+#define PPC_MODULE_FEATURE_HAS_SPE (ilog2(PPC_FEATURE_HAS_SPE))
+#define PPC_MODULE_FEATURE_HAS_EFP_SINGLE (ilog2(PPC_FEATURE_HAS_EFP_SINGLE))
+#define PPC_MODULE_FEATURE_HAS_EFP_DOUBLE (ilog2(PPC_FEATURE_HAS_EFP_DOUBLE))
+#define PPC_MODULE_FEATURE_NO_TB (ilog2(PPC_FEATURE_NO_TB))
+#define PPC_MODULE_FEATURE_POWER4 (ilog2(PPC_FEATURE_POWER4))
+#define PPC_MODULE_FEATURE_POWER5 (ilog2(PPC_FEATURE_POWER5))
+#define PPC_MODULE_FEATURE_POWER5_PLUS (ilog2(PPC_FEATURE_POWER5_PLUS))
+#define PPC_MODULE_FEATURE_CELL (ilog2(PPC_FEATURE_CELL))
+#define PPC_MODULE_FEATURE_BOOKE (ilog2(PPC_FEATURE_BOOKE))
+#define PPC_MODULE_FEATURE_SMT (ilog2(PPC_FEATURE_SMT))
+#define PPC_MODULE_FEATURE_ICACHE_SNOOP (ilog2(PPC_FEATURE_ICACHE_SNOOP))
+#define PPC_MODULE_FEATURE_ARCH_2_05 (ilog2(PPC_FEATURE_ARCH_2_05))
+#define PPC_MODULE_FEATURE_PA6T (ilog2(PPC_FEATURE_PA6T))
+#define PPC_MODULE_FEATURE_HAS_DFP (ilog2(PPC_FEATURE_HAS_DFP))
+#define PPC_MODULE_FEATURE_POWER6_EXT (ilog2(PPC_FEATURE_POWER6_EXT))
+#define PPC_MODULE_FEATURE_ARCH_2_06 (ilog2(PPC_FEATURE_ARCH_2_06))
+#define PPC_MODULE_FEATURE_HAS_VSX (ilog2(PPC_FEATURE_HAS_VSX))
+#define PPC_MODULE_FEATURE_PSERIES_PERFMON_COMPAT (ilog2(PPC_FEATURE_PSERIES_PERFMON_COMPAT))
+#define PPC_MODULE_FEATURE_TRUE_LE (ilog2(PPC_FEATURE_TRUE_LE))
+#define PPC_MODULE_FEATURE_PPC_LE (ilog2(PPC_FEATURE_PPC_LE))
+
+#define PPC_MODULE_FEATURE_ARCH_2_07 (32 + ilog2(PPC_FEATURE2_ARCH_2_07))
+#define PPC_MODULE_FEATURE_HTM (32 + ilog2(PPC_FEATURE2_HTM))
+#define PPC_MODULE_FEATURE_DSCR (32 + ilog2(PPC_FEATURE2_DSCR))
+#define PPC_MODULE_FEATURE_EBB (32 + ilog2(PPC_FEATURE2_EBB))
+#define PPC_MODULE_FEATURE_ISEL (32 + ilog2(PPC_FEATURE2_ISEL))
+#define PPC_MODULE_FEATURE_TAR (32 + ilog2(PPC_FEATURE2_TAR))
+#define PPC_MODULE_FEATURE_VEC_CRYPTO (32 + ilog2(PPC_FEATURE2_VEC_CRYPTO))
+#define PPC_MODULE_FEATURE_HTM_NOSC (32 + ilog2(PPC_FEATURE2_HTM_NOSC))
+#define PPC_MODULE_FEATURE_ARCH_3_00 (32 + ilog2(PPC_FEATURE2_ARCH_3_00))
+#define PPC_MODULE_FEATURE_HAS_IEEE128 (32 + ilog2(PPC_FEATURE2_HAS_IEEE128))
+
+#define cpu_feature(x) (x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+ if (num < 32)
+ return !!(cur_cpu_spec->cpu_user_features & 1UL << num);
+ else
+ return !!(cur_cpu_spec->cpu_user_features2 & 1UL << (num - 32));
+}
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] crypto: vmx - Convert to CPU feature based module autoloading
From: alastair @ 2016-07-13 5:47 UTC (permalink / raw)
To: mpe
Cc: benh, paulus, herbert, davem, linuxppc-dev, linux-crypto,
linux-kernel, Alastair D'Silva
In-Reply-To: <1468388840-12068-1-git-send-email-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
to automatically load the vmx_crypto module if the CPU supports
it.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
drivers/crypto/vmx/Kconfig | 2 +-
drivers/crypto/vmx/vmx.c | 6 ++----
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/vmx/Kconfig b/drivers/crypto/vmx/Kconfig
index 89d8208..a83ead1 100644
--- a/drivers/crypto/vmx/Kconfig
+++ b/drivers/crypto/vmx/Kconfig
@@ -1,7 +1,7 @@
config CRYPTO_DEV_VMX_ENCRYPT
tristate "Encryption acceleration support on P8 CPU"
depends on CRYPTO_DEV_VMX
- default y
+ default m
help
Support for VMX cryptographic acceleration instructions on Power8 CPU.
This module supports acceleration for AES and GHASH in hardware. If you
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index e163d57..5a40f2f 100644
--- a/drivers/crypto/vmx/vmx.c
+++ b/drivers/crypto/vmx/vmx.c
@@ -23,6 +23,7 @@
#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/err.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <asm/cputable.h>
#include <crypto/internal/hash.h>
@@ -43,9 +44,6 @@ int __init p8_init(void)
int ret = 0;
struct crypto_alg **alg_it;
- if (!(cur_cpu_spec->cpu_user_features2 & PPC_FEATURE2_VEC_CRYPTO))
- return -ENODEV;
-
for (alg_it = algs; *alg_it; alg_it++) {
ret = crypto_register_alg(*alg_it);
printk(KERN_INFO "crypto_register_alg '%s' = %d\n",
@@ -78,7 +76,7 @@ void __exit p8_exit(void)
crypto_unregister_shash(&p8_ghash_alg);
}
-module_init(p8_init);
+module_cpu_feature_match(PPC_MODULE_FEATURE_VEC_CRYPTO, p8_init);
module_exit(p8_exit);
MODULE_AUTHOR("Marcelo Cerri<mhcerri@br.ibm.com>");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] powerpc: Add module autoloading based on CPU features
From: alastair @ 2016-07-13 5:47 UTC (permalink / raw)
To: mpe
Cc: benh, paulus, herbert, davem, linuxppc-dev, linux-crypto,
linux-kernel, Alastair D'Silva
In-Reply-To: <1468388840-12068-1-git-send-email-alastair@au1.ibm.com>
From: Alastair D'Silva <alastair@d-silva.org>
This patch provides the necessary infrastructure to allow drivers
to be automatically loaded via UDEV. It implements the minimum
required to be able to use module_cpu_feature_match to trigger
the GENERIC_CPU_AUTOPROBE mechanisms.
The features exposed are a mirror of the cpu_user_features
(converted to an offset from a mask). This decision was made to
ensure that the behavior between features for module loading and
userspace are consistent.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/cpufeature.h | 70 +++++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+)
create mode 100644 arch/powerpc/include/asm/cpufeature.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0a9d439..a6e49db 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -164,6 +164,7 @@ config PPC
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
+ select GENERIC_CPU_AUTOPROBE
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h
new file mode 100644
index 0000000..df31627
--- /dev/null
+++ b/arch/powerpc/include/asm/cpufeature.h
@@ -0,0 +1,70 @@
+/* CPU feature definitions for module loading, used by
+ * module_cpu_feature_match(), see asm/cputable.h for powerpc CPU features
+ *
+ * Copyright 2016 Alastair D'Silva, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_POWERPC_CPUFEATURE_H
+
+#include <asm/cputable.h>
+
+/* Keep these in step with powerpc/include/asm/cputable.h */
+#define MAX_CPU_FEATURES (2 * 32)
+
+#define PPC_MODULE_FEATURE_32 (ilog2(PPC_FEATURE_32))
+#define PPC_MODULE_FEATURE_64 (ilog2(PPC_FEATURE_64))
+#define PPC_MODULE_FEATURE_601_INSTR (ilog2(PPC_FEATURE_601_INSTR))
+#define PPC_MODULE_FEATURE_HAS_ALTIVEC (ilog2(PPC_FEATURE_HAS_ALTIVEC))
+#define PPC_MODULE_FEATURE_HAS_FPU (ilog2(PPC_FEATURE_HAS_FPU))
+#define PPC_MODULE_FEATURE_HAS_MMU (ilog2(PPC_FEATURE_HAS_MMU))
+#define PPC_MODULE_FEATURE_HAS_4xxMAC (ilog2(PPC_FEATURE_HAS_4xxMAC))
+#define PPC_MODULE_FEATURE_UNIFIED_CACHE ilog2(PPC_FEATURE_UNIFIED_CACHE))
+#define PPC_MODULE_FEATURE_HAS_SPE (ilog2(PPC_FEATURE_HAS_SPE))
+#define PPC_MODULE_FEATURE_HAS_EFP_SINGLE (ilog2(PPC_FEATURE_HAS_EFP_SINGLE))
+#define PPC_MODULE_FEATURE_HAS_EFP_DOUBLE (ilog2(PPC_FEATURE_HAS_EFP_DOUBLE))
+#define PPC_MODULE_FEATURE_NO_TB (ilog2(PPC_FEATURE_NO_TB))
+#define PPC_MODULE_FEATURE_POWER4 (ilog2(PPC_FEATURE_POWER4))
+#define PPC_MODULE_FEATURE_POWER5 (ilog2(PPC_FEATURE_POWER5))
+#define PPC_MODULE_FEATURE_POWER5_PLUS (ilog2(PPC_FEATURE_POWER5_PLUS))
+#define PPC_MODULE_FEATURE_CELL (ilog2(PPC_FEATURE_CELL))
+#define PPC_MODULE_FEATURE_BOOKE (ilog2(PPC_FEATURE_BOOKE))
+#define PPC_MODULE_FEATURE_SMT (ilog2(PPC_FEATURE_SMT))
+#define PPC_MODULE_FEATURE_ICACHE_SNOOP (ilog2(PPC_FEATURE_ICACHE_SNOOP))
+#define PPC_MODULE_FEATURE_ARCH_2_05 (ilog2(PPC_FEATURE_ARCH_2_05))
+#define PPC_MODULE_FEATURE_PA6T (ilog2(PPC_FEATURE_PA6T))
+#define PPC_MODULE_FEATURE_HAS_DFP (ilog2(PPC_FEATURE_HAS_DFP))
+#define PPC_MODULE_FEATURE_POWER6_EXT (ilog2(PPC_FEATURE_POWER6_EXT))
+#define PPC_MODULE_FEATURE_ARCH_2_06 (ilog2(PPC_FEATURE_ARCH_2_06))
+#define PPC_MODULE_FEATURE_HAS_VSX (ilog2(PPC_FEATURE_HAS_VSX))
+#define PPC_MODULE_FEATURE_PSERIES_PERFMON_COMPAT (ilog2(PPC_FEATURE_PSERIES_PERFMON_COMPAT))
+#define PPC_MODULE_FEATURE_TRUE_LE (ilog2(PPC_FEATURE_TRUE_LE))
+#define PPC_MODULE_FEATURE_PPC_LE (ilog2(PPC_FEATURE_PPC_LE))
+
+#define PPC_MODULE_FEATURE_ARCH_2_07 (32 + ilog2(PPC_FEATURE2_ARCH_2_07))
+#define PPC_MODULE_FEATURE_HTM (32 + ilog2(PPC_FEATURE2_HTM))
+#define PPC_MODULE_FEATURE_DSCR (32 + ilog2(PPC_FEATURE2_DSCR))
+#define PPC_MODULE_FEATURE_EBB (32 + ilog2(PPC_FEATURE2_EBB))
+#define PPC_MODULE_FEATURE_ISEL (32 + ilog2(PPC_FEATURE2_ISEL))
+#define PPC_MODULE_FEATURE_TAR (32 + ilog2(PPC_FEATURE2_TAR))
+#define PPC_MODULE_FEATURE_VEC_CRYPTO (32 + ilog2(PPC_FEATURE2_VEC_CRYPTO))
+#define PPC_MODULE_FEATURE_HTM_NOSC (32 + ilog2(PPC_FEATURE2_HTM_NOSC))
+#define PPC_MODULE_FEATURE_ARCH_3_00 (32 + ilog2(PPC_FEATURE2_ARCH_3_00))
+#define PPC_MODULE_FEATURE_HAS_IEEE128 (32 + ilog2(PPC_FEATURE2_HAS_IEEE128))
+
+#define cpu_feature(x) (x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+ if (num < 32)
+ return !!(cur_cpu_spec->cpu_user_features & 1UL << num);
+ else
+ return !!(cur_cpu_spec->cpu_user_features2 & 1UL << (num - 32));
+}
+
+#endif /* __ASM_POWERPC_CPUFEATURE_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] Automatically load the vmx_crypto module if supported
From: alastair @ 2016-07-13 5:47 UTC (permalink / raw)
To: mpe
Cc: benh, paulus, herbert, davem, linuxppc-dev, linux-crypto,
linux-kernel, Alastair D'Silva
From: Alastair D'Silva <alastair@d-silva.org>
This series allows the vmx_crypto module to be detected and automatically
loaded via UDEV if the CPU supports the vector crypto feature.
Alastair D'Silva (2):
powerpc: Add module autoloading based on CPU features
crypto: vmx - Convert to CPU feature based module autoloading
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/cpufeature.h | 70 +++++++++++++++++++++++++++++++++++
drivers/crypto/vmx/Kconfig | 2 +-
drivers/crypto/vmx/vmx.c | 6 +--
4 files changed, 74 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/include/asm/cpufeature.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported
From: Alastair D'Silva @ 2016-07-13 5:54 UTC (permalink / raw)
To: mpe; +Cc: benh, paulus, herbert, davem, linuxppc-dev, linux-crypto,
linux-kernel
In-Reply-To: <1468388840-12068-1-git-send-email-alastair@au1.ibm.com>
On Wed, 2016-07-13 at 15:47 +1000, alastair@au1.ibm.com wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
> > This series allows the vmx_crypto module to be detected and
> automatically
> loaded via UDEV if the CPU supports the vector crypto feature.
> > Alastair D'Silva (2):
> powerpc: Add module autoloading based on CPU features
> crypto: vmx - Convert to CPU feature based module autoloading
> > arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/cpufeature.h | 70
> +++++++++++++++++++++++++++++++++++
> drivers/crypto/vmx/Kconfig | 2 +-
> drivers/crypto/vmx/vmx.c | 6 +--
> 4 files changed, 74 insertions(+), 5 deletions(-)
> create mode 100644 arch/powerpc/include/asm/cpufeature.h
Please ignore the following:
[PATCH 1/2] Allow drivers to be autoloaded.
[PATCH 2/2] Automatically load the vmx_crypto module if supported.
-- Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819
^ permalink raw reply
* Loan Offer
From: Quick Loans @ 2016-07-13 0:41 UTC (permalink / raw)
To: Recipients
Instant cash Loan with same day payout on all kinds of Loan are available at Quick Financial Home were loan is offered at 2% per annul. Email: quickloanss@foxmail.com
^ permalink raw reply
* Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS
From: Paulo Flabiano Smorigo @ 2016-07-13 13:34 UTC (permalink / raw)
To: Stewart Smith
Cc: Leonidas S. Barbosa, Stephen Rothwell, Herbert Xu, linux-kernel,
Paul Mackerras,
open list:IBM Power VMX Cryptographic instructions,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, David S. Miller
In-Reply-To: <8737nep7a8.fsf@linux.vnet.ibm.com>
Wed, Jul 13, 2016 at 01:05:03PM +1000, Stewart Smith wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > On Mon, 11 Jul 2016 16:07:39 -0300 Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> wrote:
> >>
> >> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
> >> index 2280539..813ffcc 100644
> >> --- a/drivers/crypto/vmx/aesp8-ppc.pl
> >> +++ b/drivers/crypto/vmx/aesp8-ppc.pl
> >> @@ -1,4 +1,11 @@
> >> -#!/usr/bin/env perl
> >> +#! /usr/bin/env perl
> >> +# Copyright 2014-2016 The OpenSSL Project Authors. All Rights Reserved.
> >> +#
> >> +# Licensed under the OpenSSL license (the "License"). You may not use
> >> +# this file except in compliance with the License. You can obtain a copy
> >> +# in the file LICENSE in the source distribution or at
> >> +# https://www.openssl.org/source/license.html
> >
> > So, I assume that this license is compatible with the GPLv2?
Andy released this code under the cryptogams license:
# ====================================================================
# Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
# project. The module is, however, dual licensed under OpenSSL and
# CRYPTOGAMS licenses depending on where you obtain it. For further
# details see http://www.openssl.org/~appro/cryptogams/.
# ====================================================================
The license is GPL compatible:
ALTERNATIVELY, provided that this notice is retained in full, this
product may be distributed under the terms of the GNU General Public
License (GPL), in which case the provisions of the GPL apply INSTEAD OF
those given above.
>
> https://people.gnome.org/~markmc/openssl-and-the-gpl.html has an
> explanation and points to:
> https://www.openssl.org/docs/faq.html#LEGAL2
>
> which makes it anything but clearer.
>
> it appears the answer is "probably not, unless you have an explicit
> exemption in your license"
>
> --
> Stewart Smith
> OPAL Architect, IBM.
--
Paulo Flabiano Smorigo
IBM Linux Technology Center
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 5/6] crypto: img-hash - Add support for export and import
From: Will Thomas @ 2016-07-13 14:01 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, james.hartley
In-Reply-To: <20160712074929.GA29737@gondor.apana.org.au>
Hi Herbert,
I don't see any other drivers explicitly requesting a fallback
driver by name. Anyways, should this be done using "sha1-generic"
in the crypto_alloc_ahash call when setting up the fallback tfm?
Thanks,
Will
On 12/07/16 08:49, Herbert Xu wrote:
> Will Thomas <will.thomas@imgtec.com> wrote:
>>
>> @@ -714,9 +740,12 @@ static struct ahash_alg img_algs[] = {
>> .update = img_hash_update,
>> .final = img_hash_final,
>> .finup = img_hash_finup,
>> + .export = img_hash_export,
>> + .import = img_hash_import,
>> .digest = img_hash_digest,
>> .halg = {
>> .digestsize = MD5_DIGEST_SIZE,
>> + .statesize = sizeof(struct md5_state),
>
> This is wrong. The fallback state size is not guaranteed to be
> the same as the generic MD5. I suppose the easiest fix is to
> explicitly request for md5-generic/sha1-generic/etc. when you
> allocate the fallback.
>
> Thanks,
>
^ permalink raw reply
* Re: [PATCH 2/6] crypto: img-hash - Fix hash request context
From: Will Thomas @ 2016-07-13 14:45 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160712074300.GA29696@gondor.apana.org.au>
On 12/07/16 08:43, Herbert Xu wrote:
> Will Thomas <will.thomas@imgtec.com> wrote:
>> Move 0 length buffer to end of structure to stop overwriting
>> fallback request data. This doesn't cause a bug itself as the
>> buffer is never used alongside the fallback but should be
>> changed.
>>
>> Signed-off-by: Will Thomas <will.thomas@imgtec.com>
>> Reviewed-by: James Hartley <james.hartley@imgtec.com>
>
> This points out another bug, the fallback can have its own ctx
> following the request.
>
> So the set_reqsize call needs to be adjusted to take that into
> account.
Will be an additional patch in v2 to fix this.
Thanks,
Will
^ permalink raw reply
* Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS
From: Stephen Rothwell @ 2016-07-13 15:11 UTC (permalink / raw)
To: Paulo Flabiano Smorigo
Cc: Stewart Smith, Leonidas S. Barbosa, Herbert Xu, linux-kernel,
Paul Mackerras,
open list:IBM Power VMX Cryptographic instructions,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, David S. Miller
In-Reply-To: <20160713133427.GA20432@dublin>
Hi Paulo,
On Wed, 13 Jul 2016 10:34:27 -0300 Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> wrote:
>
> Wed, Jul 13, 2016 at 01:05:03PM +1000, Stewart Smith wrote:
> > Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > > On Mon, 11 Jul 2016 16:07:39 -0300 Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> wrote:
> > >>
> > >> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
> > >> index 2280539..813ffcc 100644
> > >> --- a/drivers/crypto/vmx/aesp8-ppc.pl
> > >> +++ b/drivers/crypto/vmx/aesp8-ppc.pl
> > >> @@ -1,4 +1,11 @@
> > >> -#!/usr/bin/env perl
> > >> +#! /usr/bin/env perl
> > >> +# Copyright 2014-2016 The OpenSSL Project Authors. All Rights Reserved.
> > >> +#
> > >> +# Licensed under the OpenSSL license (the "License"). You may not use
> > >> +# this file except in compliance with the License. You can obtain a copy
> > >> +# in the file LICENSE in the source distribution or at
> > >> +# https://www.openssl.org/source/license.html
> > >
> > > So, I assume that this license is compatible with the GPLv2?
>
> Andy released this code under the cryptogams license:
>
> # ====================================================================
> # Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
> # project. The module is, however, dual licensed under OpenSSL and
> # CRYPTOGAMS licenses depending on where you obtain it. For further
> # details see http://www.openssl.org/~appro/cryptogams/.
> # ====================================================================
Yeah, this license statement is already in the file being patched, so
why is the above license (and Copyright notice) being added above the
existing one?
> The license is GPL compatible:
Good, thanks.
> ALTERNATIVELY, provided that this notice is retained in full, this
> product may be distributed under the terms of the GNU General Public
> License (GPL), in which case the provisions of the GPL apply INSTEAD OF
> those given above.
Which is not in this file or the patch, but presumably in the referred
to web page.
Of course, I am not a lawyer :-)
--
Cheers,
Stephen Rothwell
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS
From: Paulo Flabiano Smorigo @ 2016-07-13 16:02 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Stewart Smith, Leonidas S. Barbosa, Herbert Xu, linux-kernel,
Paul Mackerras,
open list:IBM Power VMX Cryptographic instructions,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, David S. Miller
In-Reply-To: <20160714011158.46c386f4@canb.auug.org.au>
Thu, Jul 14, 2016 at 01:11:58AM +1000, Stephen Rothwell wrote:
> Hi Paulo,
>
> On Wed, 13 Jul 2016 10:34:27 -0300 Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> wrote:
> >
> > Wed, Jul 13, 2016 at 01:05:03PM +1000, Stewart Smith wrote:
> > > Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > > > On Mon, 11 Jul 2016 16:07:39 -0300 Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> wrote:
> > > >>
> > > >> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
> > > >> index 2280539..813ffcc 100644
> > > >> --- a/drivers/crypto/vmx/aesp8-ppc.pl
> > > >> +++ b/drivers/crypto/vmx/aesp8-ppc.pl
> > > >> @@ -1,4 +1,11 @@
> > > >> -#!/usr/bin/env perl
> > > >> +#! /usr/bin/env perl
> > > >> +# Copyright 2014-2016 The OpenSSL Project Authors. All Rights Reserved.
> > > >> +#
> > > >> +# Licensed under the OpenSSL license (the "License"). You may not use
> > > >> +# this file except in compliance with the License. You can obtain a copy
> > > >> +# in the file LICENSE in the source distribution or at
> > > >> +# https://www.openssl.org/source/license.html
> > > >
> > > > So, I assume that this license is compatible with the GPLv2?
> >
> > Andy released this code under the cryptogams license:
> >
> > # ====================================================================
> > # Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
> > # project. The module is, however, dual licensed under OpenSSL and
> > # CRYPTOGAMS licenses depending on where you obtain it. For further
> > # details see http://www.openssl.org/~appro/cryptogams/.
> > # ====================================================================
>
> Yeah, this license statement is already in the file being patched, so
> why is the above license (and Copyright notice) being added above the
> existing one?
aesp8-ppc.pl from Linux is almost the same as the one from OpenSSL and we do
that so we can keep it updated on both projects.
The above license lines were added to all pl files in OpenSSL so it ended up
here but since the author published it as cryptogams too we are ok.
>
> > The license is GPL compatible:
>
> Good, thanks.
>
> > ALTERNATIVELY, provided that this notice is retained in full, this
> > product may be distributed under the terms of the GNU General Public
> > License (GPL), in which case the provisions of the GPL apply INSTEAD OF
> > those given above.
>
> Which is not in this file or the patch, but presumably in the referred
> to web page.
Yes, that comment is from the url pointed in the code.
>
> Of course, I am not a lawyer :-)
> --
> Cheers,
> Stephen Rothwell
>
--
Paulo Flabiano Smorigo
IBM Linux Technology Center
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Fast Loans
From: Financial Service @ 2016-07-13 12:27 UTC (permalink / raw)
To: Recipients
Hae lainaa 3% vastaus tähän viestiin lisätietoja
Apply for a loan at 3% reply to this Email for more Info
^ permalink raw reply
* Re: [PATCH] DH support: add KDF handling support
From: Mat Martineau @ 2016-07-13 23:17 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Mat Martineau, David Howells, keyrings, linux-crypto
In-Reply-To: <1652054.TS73CfBaWe@positron.chronox.de>
Stephan,
On Tue, 12 Jul 2016, Stephan Mueller wrote:
> Hi Mat, David,
>
> During the development of this patch, I saw that the test
> framework seems to be broken: when I change the expected
> values by one bit, the test framework will still mark the
> received result as PASS even though the returned data does
> not match the expected data.
I tracked this down to the expect_payload function in the test framework,
which does not properly handle multiline strings. I'll send a patch that
adds a new expect_multiline function that should handle multiline output
correctly.
>
> ---8<----
>
> Add the interface logic to support DH with KDF handling support.
>
> The dh_compute code now allows the following options:
>
> - no KDF support / output of raw DH shared secret:
> dh_compute <private> <prime> <base>
>
> - KDF support without "other information" string:
> dh_compute <private> <prime> <base> <output length> <KDF type>
Why is <output length> needed? Can it be determined from <KDF type>?
>
> - KDF support with "other information string:
> dh_compute <private> <prime> <base> <output length> <KDF type> <OI
> string>
>
> The test to verify the code is based on a test vector used for the CAVS
> testing of SP800-56A.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
> keyctl.c | 14 +++++-
> keyutils.c | 48 ++++++++++++++++++
> keyutils.h | 13 +++++
> tests/keyctl/dh_compute/valid/runtest.sh | 83 ++++++++++++++++++++++++++++++++
> 4 files changed, 156 insertions(+), 2 deletions(-)
>
> diff --git a/keyctl.c b/keyctl.c
> index edb03de..32478b3 100644
> --- a/keyctl.c
> +++ b/keyctl.c
> @@ -1638,14 +1638,24 @@ static void act_keyctl_dh_compute(int argc, char *argv[])
> char *p;
> int ret, sep, col;
>
> - if (argc != 4)
> + if (argc != 4 && argc != 6 && argc != 7)
> format();
>
> private = get_key_id(argv[1]);
> prime = get_key_id(argv[2]);
> base = get_key_id(argv[3]);
>
> - ret = keyctl_dh_compute_alloc(private, prime, base, &buffer);
> + if (argc == 4)
> + ret = keyctl_dh_compute_alloc(private, prime, base, &buffer);
> + else if (argc == 6)
> + ret = keyctl_dh_compute_kdf(private, prime, base, argv[4],
> + argv[5], NULL, &buffer);
> + else if (argc == 7)
> + ret = keyctl_dh_compute_kdf(private, prime, base, argv[4],
> + argv[5], argv[6], &buffer);
> + else
> + error("dh_compute: unknown number of arguments");
> +
> if (ret < 0)
> error("keyctl_dh_compute_alloc");
>
> diff --git a/keyutils.c b/keyutils.c
> index 2a69304..ffdd622 100644
> --- a/keyutils.c
> +++ b/keyutils.c
> @@ -386,6 +386,54 @@ int keyctl_dh_compute_alloc(key_serial_t private, key_serial_t prime,
> }
>
> /*
> + * fetch DH computation results processed by a KDF into an
> + * allocated buffer
> + * - resulting buffer has an extra NUL added to the end
> + * - returns count (not including extraneous NUL)
> + */
> +int keyctl_dh_compute_kdf(key_serial_t private, key_serial_t prime,
> + key_serial_t base, char *len, char *kdfname,
> + char *otherinfo, void **_buffer)
All of the other keyctl_* wrappers (without the _alloc) just do the
syscall, with some packing/unpacking of structs where needed. The
allocation behavior below is only found in the *_alloc functions (in the
"utilities" section of keyutils.h) - I think it's worthwhile to have both
keyctl_dh_compute_kdf() (for pre-allocated buffers) and
keyctl_dh_compute_kdf_alloc().
> +{
> + char *buf;
> + unsigned long buflen;
> + int ret;
> + struct keyctl_dh_params params = { .private = private,
> + .prime = prime,
> + .base = base };
> + struct keyctl_kdf_params kdfparams;
> +
> + buflen = strtoul(len, NULL, 10);
The string to integer conversion needs to be done in
act_keyctl_dh_compute(). Length can be passed in as a size_t if it's
needed.
> + if (buflen > KEYCTL_KDF_MAX_OUTPUTLEN)
> + return -1;
> +
> + buf = malloc(buflen + 1);
The other _alloc functions exist because the buffer length isn't known to
the caller in advance. If the buffer length is known in advance, the
caller should be allocating the buffer.
keyctl_dh_compute makes two syscalls: one to determine the buffer length,
and one to do the DH calculations.
> + if (!buf)
> + return -1;
> +
> + if (otherinfo) {
> + kdfparams.kdfname = kdfname;
> + kdfparams.kdfnamelen = strlen(kdfname);
If kdfname is a null-terminated string, then kdfnamelen seems
unneccessary. I haven't reviewed the kernel side yet, but may comment more
there. There are other examples of null-terminated string usage in the
keyctl API, I'll comment more on this in the kernel patches.
> + kdfparams.otherinfo = otherinfo;
> + kdfparams.otherinfolen = strlen(otherinfo);
Same for otherinfolen.
> + } else {
> + kdfparams.kdfname = kdfname;
> + kdfparams.kdfnamelen = strlen(kdfname);
> + kdfparams.otherinfo = NULL;
> + kdfparams.otherinfolen = 0;
> + }
> + ret = keyctl(KEYCTL_DH_COMPUTE, ¶ms, buf, buflen, &kdfparams);
> + if (ret < 0) {
> + free(buf);
> + return -1;
> + }
> +
> + buf[ret] = 0;
> + *_buffer = buf;
> + return ret;
> +}
> +
> +/*
> * Depth-first recursively apply a function over a keyring tree
> */
> static int recursive_key_scan_aux(key_serial_t parent, key_serial_t key,
> diff --git a/keyutils.h b/keyutils.h
> index b321aa8..5026270 100644
> --- a/keyutils.h
> +++ b/keyutils.h
> @@ -108,6 +108,16 @@ struct keyctl_dh_params {
> key_serial_t base;
> };
>
> +struct keyctl_kdf_params {
> +#define KEYCTL_KDF_MAX_OUTPUTLEN 1024 /* max length of KDF output */
> +#define KEYCTL_KDF_MAX_STRING_LEN 64 /* maximum length of strings */
It's better to leave this information out of the userspace as it may
change depending on the kernel version. Let the kernel return an error if
the lengths exceed limits.
> + char *kdfname;
> + uint32_t kdfnamelen;
> + char *otherinfo;
> + uint32_t otherinfolen;
> + uint32_t flags;
> +};
> +
> /*
> * syscall wrappers
> */
> @@ -172,6 +182,9 @@ extern int keyctl_read_alloc(key_serial_t id, void **_buffer);
> extern int keyctl_get_security_alloc(key_serial_t id, char **_buffer);
> extern int keyctl_dh_compute_alloc(key_serial_t private, key_serial_t prime,
> key_serial_t base, void **_buffer);
> +int keyctl_dh_compute_kdf(key_serial_t private, key_serial_t prime,
> + key_serial_t base, char *len, char *kdfname,
> + char *otherinfo, void **_buffer);
>
> typedef int (*recursive_key_scanner_t)(key_serial_t parent, key_serial_t key,
> char *desc, int desc_len, void *data);
> diff --git a/tests/keyctl/dh_compute/valid/runtest.sh b/tests/keyctl/dh_compute/valid/runtest.sh
> index 40ec387..1c77268 100644
> --- a/tests/keyctl/dh_compute/valid/runtest.sh
> +++ b/tests/keyctl/dh_compute/valid/runtest.sh
> @@ -80,6 +80,89 @@ marker "COMPUTE DH PUBLIC KEY"
> dh_compute $privateid $primeid $generatorid
> expect_payload payload $public
>
> +
> +################################################################
> +# Testing DH compute with KDF according to SP800-56A
> +#
> +# test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/keymgmt/KASTestVectorsFFC2014.zip
> +################################################################
> +
> +# SHA-256
> +
> +# XephemCAVS
> +private="\x81\xb2\xc6\x5f\x5c\xba\xc0\x0b\x13\x53\xac\x38\xbd\x77\xa2\x5a"
> +private+="\x86\x50\xed\x48\x5e\x41\x3e\xac\x1d\x6c\x48\x85"
> +
> +# P
> +prime="\xa3\xcc\x62\x23\xe5\x0c\x6e\x3f\x7b\xb0\x58\x1d\xcb\x9e\x9f\xf0"
> +prime+="\x2c\x58\x07\x68\x32\x8a\x15\x20\x7b\x1c\x32\x31\x7f\xb7\x84\x96"
> +prime+="\x81\x5e\x3c\xf7\xf9\xd0\x9c\xcb\x9f\xa8\x40\xff\x47\x98\x51\x1a"
> +prime+="\x17\xb5\x59\x28\x72\x1e\x5d\xfb\xcc\xc5\x41\x47\xe0\xf0\x5f\x85"
> +prime+="\xb3\xac\x41\x0b\x6a\xe3\xf5\x9b\x79\x6f\x3f\xea\xc7\xfc\x52\x49"
> +prime+="\x21\x7e\xb2\xa0\x45\x88\x29\x3a\x5a\xde\x22\x78\x79\xf4\x6c\xeb"
> +prime+="\x56\x45\x7b\x5c\x43\x12\x93\xe5\xe1\x04\xd1\xb9\x64\xbd\x2c\xdf"
> +prime+="\xde\xff\xa0\x40\x49\xa9\x1e\x67\xee\x8c\x86\xe9\x44\xf0\x4f\x94"
> +prime+="\x4a\x30\xe3\x61\xf8\xd1\x5d\x17\xe5\x01\x0c\xab\xb4\xef\x40\xc0"
> +prime+="\xeb\xa5\xf4\xa2\x52\xd4\xfd\x6c\xf9\xda\xe6\x0e\x86\xe4\xb3\x00"
> +prime+="\x9b\x1d\xfc\x92\x66\x70\x35\x72\x61\x58\x7a\xd0\x5c\x00\xa6\xc6"
> +prime+="\xf0\x10\x6c\xec\x8f\xc5\x91\x31\x51\x50\x84\xa8\x70\x59\x41\x65"
> +prime+="\xb4\x93\x90\xdb\x2d\x00\xe7\x53\x8f\x23\x0d\x53\x2f\x4a\x4e\xca"
> +prime+="\x83\x09\xd7\x07\xc0\xb3\x83\x5c\xee\x04\xf3\xca\x55\x8a\x22\xc6"
> +prime+="\xb5\x20\xfe\x25\xde\x6f\xfa\x90\xef\xda\x49\x27\xd0\x18\x59\x4c"
> +prime+="\x0c\x0b\x77\x06\x73\x93\xb7\xf1\xe0\xfc\x7c\xf2\x16\xaf\xf3\x9f"
> +
> +# YephemIUT
> +xa="\x9a\x70\x82\x2d\x3f\x06\x12\x3d\x0e\x51\x8e\xe1\x16\x51\xe5\xf6"
> +xa+="\xb1\x19\xdc\x3b\x97\xd5\xb1\xc0\xa2\xa6\xf6\xde\x94\x25\x64\xba"
> +xa+="\x10\x06\x1e\xec\xde\xb7\x36\x9c\xa5\x37\x49\x9e\x04\xb0\x36\xe9"
> +xa+="\x7f\x44\x5a\x95\x6f\x63\x69\xae\x6e\x63\xfd\x27\xea\xe3\xe3\x47"
> +xa+="\x85\x54\x47\xd3\xba\xc1\xc6\x0c\x10\xe7\x35\x07\x72\xc6\xc0\xc6"
> +xa+="\xfb\xf9\xca\x3e\x38\xf0\xe8\x65\x88\x25\xd3\xb2\x0f\x1f\x02\x8f"
> +xa+="\x35\xe3\x4d\x12\x35\x10\x3d\xf2\x33\x9b\x5b\x09\x9d\x3f\xe3\xe5"
> +xa+="\x34\x6a\x69\x16\x42\xba\xc5\xb0\xbb\x03\xcd\x5d\x04\xd7\x56\x26"
> +xa+="\x21\x49\x3f\xf1\xc4\x27\x3b\x6a\x45\xc5\xec\xb0\xb5\xe9\x08\xa0"
> +xa+="\xf9\xf5\x62\x28\x2e\x85\x3e\xfc\x9a\x7e\xa1\x12\xe9\x47\x4f\xf6"
> +xa+="\x94\x18\xf7\xc4\x7a\xe9\x66\xd4\x52\x4c\xa1\x70\x1b\x60\xa4\xbe"
> +xa+="\x15\xc7\x5e\x27\xb4\x05\x80\x64\x68\x15\x6e\x02\xcb\xc5\x8f\xf4"
> +xa+="\x66\x3c\x96\xac\x0c\x87\x36\x81\x35\xfa\x9b\x0b\xb6\x33\x7a\xe2"
> +xa+="\x58\x52\x1d\x7d\x60\xc2\xa9\x1b\x4e\xd7\x72\xad\x65\x03\x40\x49"
> +xa+="\x97\xf6\x79\x9d\xf6\x63\xa8\x99\x9c\xfd\x74\x7f\xa0\x67\xb9\x05"
> +xa+="\x8a\xb3\x3b\xc1\x45\x94\x36\x6f\x28\xf5\xa2\xd9\x00\xb6\x46\x7a"
> +
> +# Z
> +shared="0fdbd9a2 ebf50cba 489b4e4d 7cd6924a 42ee6324 a26988b2 22bc38e6 9cc445f1\n"
> +shared+="eb47c1a4 62eca39f 39bcd7b8 19dede51 30bc38da ec99c16f 40a4e5c1 9c97b796\n"
> +shared+="8b41823d a0650e37 13c73e6f 5f2a9dff 2e67dbf5 40ee66f4 e694c28f ba1d604b\n"
> +shared+="71b57b8a eeb67a35 ba425a38 490b6fb9 f713db22 6f893b7a 8962f426 ba3046fb\n"
> +shared+="cff8538c 16f583e8 ae947672 0ba55ff9 75b440d0 c4565cc7 5837d23a fea61a39\n"
> +shared+="e0b7f6c4 e24c2154 7eb19fce f8dbed10 b06a9cce 971c0f0f ba7c1d5c b5035eaa\n"
> +shared+="4fddd3ba fe757339 e3321e3e 4ebfe9e7 9c6c0401 4df63cf9 28d0a2c0 5b2d5521\n"
> +shared+="030c35f1 c84c97fe 64cad509 8012a003 d52d24c4 1a1f9348 b7575251 3facb02f\n"
> +
> +# OI
> +otherinfo="\xa1\xb2\xc3\xd4\xe5\x43\x41\x56\x53\x69\x64\x0d\x64\xc1\xb2"
> +otherinfo+="\x33\x61\xb2\x61\xde\x78\x68\x8e\xa8\x65\xfc\xff\x11\x3c\x84"
> +
> +# DKM
> +derived="8284e313 02c8a26b 393ec52d 9f9e0882\n"
> +
> +pcreate_key "-e $prime" user dh:prime @s
> +expect_keyid primeid
> +
> +pcreate_key "-e $xa" user dh:xa @s
> +expect_keyid xaid
> +
> +pcreate_key "-e $private" user dh:private @s
> +expect_keyid privateid
> +
> +marker "COMPUTE DH SHARED SECRET"
> +dh_compute $privateid $primeid $xaid
> +expect_payload payload $shared
As I mentioned at the top, we'll need an 'expect_multiline' function that
handles values like $shared.
> +
> +marker "COMPUTE DERIVED KEY FROM DH SHARED SECRET (SHA-256)"
> +dh_compute $privateid $primeid $xaid 16 "kdf_ctr(sha256)" "$(echo -e -n $otherinfo)"
> +expect_payload payload $derived
Have you checked that expect_payload works correctly in this case? Seems
like it should, since the output fits on one line.
> +
> echo "++++ FINISHED TEST: $result" >>$OUTPUTFILE
>
> # --- then report the results in the database ---
> --
> 2.7.4
>
>
>
--
Mat Martineau
Intel OTC
^ permalink raw reply
* Re: [V2][PATCH 1/2] PKCS#7: Fix kernel panic when referring to the empty AuthorityKeyIdentifier
From: Dave Young @ 2016-07-14 2:16 UTC (permalink / raw)
To: Lans Zhang; +Cc: dhowells, kexec, vgoyal, bhe, linux-crypto, herbert
In-Reply-To: <1468416937-21237-1-git-send-email-jia.zhang@windriver.com>
Cc crpto list
On 07/13/16 at 09:35pm, Lans Zhang wrote:
> This fix resolves the following kernel panic if the empty AuthorityKeyIdentifier employed.
>
> [ 459.041989] PKEY: <==public_key_verify_signature() = 0
> [ 459.041993] PKCS7: Verified signature 1
> [ 459.041995] PKCS7: ==> pkcs7_verify_sig_chain()
> [ 459.041999] PKCS7: verify Sample DB Certificate for SCP: 01
> [ 459.042002] PKCS7: - issuer Sample KEK Certificate for SCP
> [ 459.042014] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 459.042135] IP: [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0
> [ 459.042217] PGD 739e6067 PUD 77719067 PMD 0
> [ 459.042286] Oops: 0000 [#1] PREEMPT SMP
> [ 459.042328] Modules linked in:
> [ 459.042368] CPU: 0 PID: 474 Comm: kexec Not tainted 4.7.0-rc7-WR8.0.0.0_standard+ #18
> [ 459.042462] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 10/09/2014
> [ 459.042586] task: ffff880073a50000 ti: ffff8800738e8000 task.ti: ffff8800738e8000
> [ 459.042675] RIP: 0010:[<ffffffff813e7b4c>] [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0
> [ 459.042784] RSP: 0018:ffff8800738ebd58 EFLAGS: 00010246
> [ 459.042845] RAX: 0000000000000000 RBX: ffff880076b7da80 RCX: 0000000000000006
> [ 459.042929] RDX: 0000000000000001 RSI: ffffffff81c85001 RDI: ffffffff81ca00a9
> [ 459.043014] RBP: ffff8800738ebd98 R08: 0000000000000400 R09: ffff8800788a304c
> [ 459.043098] R10: 0000000000000000 R11: 00000000000060ca R12: ffff8800769a2bc0
> [ 459.043182] R13: ffff880077358300 R14: 0000000000000000 R15: ffff8800769a2dc0
> [ 459.043268] FS: 00007f24cc741700(0000) GS:ffff880074e00000(0000) knlGS:0000000000000000
> [ 459.043365] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 459.043431] CR2: 0000000000000000 CR3: 0000000073a36000 CR4: 00000000001006f0
> [ 459.043514] Stack:
> [ 459.043530] 0000000000000000 ffffffbf00000020 31ffffff813e68b0 0000000000000002
> [ 459.043644] ffff8800769a2bc0 0000000000000000 00000000007197b8 0000000000000002
> [ 459.043756] ffff8800738ebdd8 ffffffff81153fb1 0000000000000000 0000000000000000
> [ 459.043869] Call Trace:
> [ 459.043898] [<ffffffff81153fb1>] verify_pkcs7_signature+0x61/0x140
> [ 459.043974] [<ffffffff813e7f0b>] verify_pefile_signature+0x2cb/0x830
> [ 459.044052] [<ffffffff813e8470>] ? verify_pefile_signature+0x830/0x830
> [ 459.044134] [<ffffffff81048e25>] bzImage64_verify_sig+0x15/0x20
> [ 459.046332] [<ffffffff81046e09>] arch_kexec_kernel_verify_sig+0x29/0x40
> [ 459.048552] [<ffffffff810f10e4>] SyS_kexec_file_load+0x1f4/0x6c0
> [ 459.050768] [<ffffffff81050e36>] ? __do_page_fault+0x1b6/0x550
> [ 459.052996] [<ffffffff8199241f>] entry_SYSCALL_64_fastpath+0x17/0x93
> [ 459.055242] Code: e8 0a d6 ff ff 85 c0 0f 88 7a fb ff ff 4d 39 fd 4d 89 7d 08 74 45 4d 89 fd e9 14 fe ff ff 4d 8b 76 08 31 c0 48 c7 c7 a9 00 ca 81 <41> 0f b7 36 49 8d 56 02 e8 d0 91 d6 ff 4d 8b 3c 24 4d 85 ff 0f
> [ 459.060535] RIP [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0
> [ 459.063040] RSP <ffff8800738ebd58>
> [ 459.065456] CR2: 0000000000000000
> [ 459.075998] ---[ end trace c15f0e897cda28dc ]---
>
> Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> ---
> crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
> index 44b746e..2ffd697 100644
> --- a/crypto/asymmetric_keys/pkcs7_verify.c
> +++ b/crypto/asymmetric_keys/pkcs7_verify.c
> @@ -227,7 +227,7 @@ static int pkcs7_verify_sig_chain(struct pkcs7_message *pkcs7,
> if (asymmetric_key_id_same(p->id, auth))
> goto found_issuer_check_skid;
> }
> - } else {
> + } else if (sig->auth_ids[1]) {
> auth = sig->auth_ids[1];
> pr_debug("- want %*phN\n", auth->len, auth->data);
> for (p = pkcs7->certs; p; p = p->next) {
> --
> 1.9.1
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [V2][PATCH 2/2] pefile: Fix the failure of calculation for digest
From: Dave Young @ 2016-07-14 2:18 UTC (permalink / raw)
To: Lans Zhang; +Cc: dhowells, kexec, vgoyal, bhe, herbert, linux-crypto
In-Reply-To: <1468416937-21237-2-git-send-email-jia.zhang@windriver.com>
Cc crypto list
On 07/13/16 at 09:35pm, Lans Zhang wrote:
> The commit e68503bd68 forgot to set digest_len and thus cause the following
> error reported by kexec when launching a crash kernel:
> "kexec_file_load failed: Bad message"
>
> Fixes: e68503bd68 (KEYS: Generalise system_verify_data() to provide access to internal content)
> Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> ---
> crypto/asymmetric_keys/mscode_parser.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/mscode_parser.c b/crypto/asymmetric_keys/mscode_parser.c
> index 6a76d5c..9492e1c 100644
> --- a/crypto/asymmetric_keys/mscode_parser.c
> +++ b/crypto/asymmetric_keys/mscode_parser.c
> @@ -124,5 +124,10 @@ int mscode_note_digest(void *context, size_t hdrlen,
> struct pefile_context *ctx = context;
>
> ctx->digest = kmemdup(value, vlen, GFP_KERNEL);
> - return ctx->digest ? 0 : -ENOMEM;
> + if (!ctx->digest)
> + return -ENOMEM;
> +
> + ctx->digest_len = vlen;
> +
> + return 0;
> }
> --
> 1.9.1
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported
From: Balbir Singh @ 2016-07-14 3:34 UTC (permalink / raw)
To: Alastair D'Silva
Cc: mpe, benh, paulus, herbert, davem, linuxppc-dev, linux-crypto,
linux-kernel
In-Reply-To: <1468389299.4705.26.camel@au1.ibm.com>
On Wed, Jul 13, 2016 at 03:54:59PM +1000, Alastair D'Silva wrote:
> On Wed, 2016-07-13 at 15:47 +1000, alastair@au1.ibm.com wrote:
> > From: Alastair D'Silva <alastair@d-silva.org>
> > > This series allows the vmx_crypto module to be detected and
> > automatically
> > loaded via UDEV if the CPU supports the vector crypto feature.
> > > Alastair D'Silva (2):
> > powerpc: Add module autoloading based on CPU features
> > crypto: vmx - Convert to CPU feature based module autoloading
> > > arch/powerpc/Kconfig | 1 +
> > arch/powerpc/include/asm/cpufeature.h | 70
> > +++++++++++++++++++++++++++++++++++
> > drivers/crypto/vmx/Kconfig | 2 +-
> > drivers/crypto/vmx/vmx.c | 6 +--
> > 4 files changed, 74 insertions(+), 5 deletions(-)
> > create mode 100644 arch/powerpc/include/asm/cpufeature.h
>
> Please ignore the following:
> [PATCH 1/2] Allow drivers to be autoloaded.
> [PATCH 2/2] Automatically load the vmx_crypto module if supported.
>
Do you want to repost the series?
Balbir
^ permalink raw reply
* Re: [PATCH] DH support: add KDF handling support
From: Stephan Mueller @ 2016-07-14 6:54 UTC (permalink / raw)
To: Mat Martineau; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1607131520480.52983@mjmartin-mac01.local>
Am Mittwoch, 13. Juli 2016, 16:17:12 schrieb Mat Martineau:
Hi Mat,
>
> > ---8<----
> >
> > Add the interface logic to support DH with KDF handling support.
> >
> > The dh_compute code now allows the following options:
> >
> > - no KDF support / output of raw DH shared secret:
> > dh_compute <private> <prime> <base>
> >
> > - KDF support without "other information" string:
> > dh_compute <private> <prime> <base> <output length> <KDF type>
>
> Why is <output length> needed? Can it be determined from <KDF type>?
The KDF can be considered as a random number generator that is seeded by the
shared secret. I.e. it can produce arbitrary string lengths. There is no
default string length for any given KDF.
Note, as shared secrets potentially post-processed by a KDF usually are again
used as key or data encryption keys, they need to be truncated/expanded to a
specific length anyway. A KDF inherently provides the truncation support to
any arbitrary length. Thus, I would think that the caller needs to provide
that length but does not need to truncate the output itself.
>
> > - KDF support with "other information string:
> > dh_compute <private> <prime> <base> <output length> <KDF type> <OI
> > string>
> >
> > The test to verify the code is based on a test vector used for the CAVS
> > testing of SP800-56A.
> >
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
> > ---
> > keyctl.c | 14 +++++-
> > keyutils.c | 48 ++++++++++++++++++
> > keyutils.h | 13 +++++
> > tests/keyctl/dh_compute/valid/runtest.sh | 83
> > ++++++++++++++++++++++++++++++++ 4 files changed, 156 insertions(+), 2
> > deletions(-)
> >
> > diff --git a/keyctl.c b/keyctl.c
> > index edb03de..32478b3 100644
> > --- a/keyctl.c
> > +++ b/keyctl.c
> > @@ -1638,14 +1638,24 @@ static void act_keyctl_dh_compute(int argc, char
> > *argv[])>
> > char *p;
> > int ret, sep, col;
> >
> > - if (argc != 4)
> > + if (argc != 4 && argc != 6 && argc != 7)
> >
> > format();
> >
> > private = get_key_id(argv[1]);
> > prime = get_key_id(argv[2]);
> > base = get_key_id(argv[3]);
> >
> > - ret = keyctl_dh_compute_alloc(private, prime, base, &buffer);
> > + if (argc == 4)
> > + ret = keyctl_dh_compute_alloc(private, prime, base, &buffer);
> > + else if (argc == 6)
> > + ret = keyctl_dh_compute_kdf(private, prime, base, argv[4],
> > + argv[5], NULL, &buffer);
> > + else if (argc == 7)
> > + ret = keyctl_dh_compute_kdf(private, prime, base, argv[4],
> > + argv[5], argv[6], &buffer);
> > + else
> > + error("dh_compute: unknown number of arguments");
> > +
> >
> > if (ret < 0)
> >
> > error("keyctl_dh_compute_alloc");
> >
> > diff --git a/keyutils.c b/keyutils.c
> > index 2a69304..ffdd622 100644
> > --- a/keyutils.c
> > +++ b/keyutils.c
> > @@ -386,6 +386,54 @@ int keyctl_dh_compute_alloc(key_serial_t private,
> > key_serial_t prime, }
> >
> > /*
> > + * fetch DH computation results processed by a KDF into an
> > + * allocated buffer
> > + * - resulting buffer has an extra NUL added to the end
> > + * - returns count (not including extraneous NUL)
> > + */
> > +int keyctl_dh_compute_kdf(key_serial_t private, key_serial_t prime,
> > + key_serial_t base, char *len, char *kdfname,
> > + char *otherinfo, void **_buffer)
>
> All of the other keyctl_* wrappers (without the _alloc) just do the
> syscall, with some packing/unpacking of structs where needed. The
> allocation behavior below is only found in the *_alloc functions (in the
> "utilities" section of keyutils.h) - I think it's worthwhile to have both
> keyctl_dh_compute_kdf() (for pre-allocated buffers) and
> keyctl_dh_compute_kdf_alloc().
Thank you for the note. I will change the code accordingly.
Though, shall I stuff the wrapper code back into the existing dh_compute
functions or can I leave them as separate functions?
>
> > +{
> > + char *buf;
> > + unsigned long buflen;
> > + int ret;
> > + struct keyctl_dh_params params = { .private = private,
> > + .prime = prime,
> > + .base = base };
> > + struct keyctl_kdf_params kdfparams;
> > +
> > + buflen = strtoul(len, NULL, 10);
>
> The string to integer conversion needs to be done in
> act_keyctl_dh_compute(). Length can be passed in as a size_t if it's
> needed.
>
Ok, will do.
> > + if (buflen > KEYCTL_KDF_MAX_OUTPUTLEN)
> > + return -1;
> > +
> > + buf = malloc(buflen + 1);
>
> The other _alloc functions exist because the buffer length isn't known to
> the caller in advance. If the buffer length is known in advance, the
> caller should be allocating the buffer.
With the implementation of the _alloc and "non-alloc" function, I would assume
that this comment should be covered.
>
> keyctl_dh_compute makes two syscalls: one to determine the buffer length,
> and one to do the DH calculations.
I am aware of that, but as explained above, in case of a KDF, there is no
specifically required buffer size. Any buffer size the caller provides is
supported and will be filled with data. Thus, in the KDF case, we can skip the
first call.
>
> > + if (!buf)
> > + return -1;
> > +
> > + if (otherinfo) {
> > + kdfparams.kdfname = kdfname;
> > + kdfparams.kdfnamelen = strlen(kdfname);
>
> If kdfname is a null-terminated string, then kdfnamelen seems
> unneccessary. I haven't reviewed the kernel side yet, but may comment more
> there. There are other examples of null-terminated string usage in the
> keyctl API, I'll comment more on this in the kernel patches.
Please let me know on the kernel side, how you would like to handle it. Note,
we only need that length information to ensure copy_from_user copies a maximum
buffer length anyway.
The string is used to find the proper crypto implementation via the kernel
crypto API. The kernel crypto API will limit the maximum number of parsed
bytes to 64 already.
>
> > + kdfparams.otherinfo = otherinfo;
> > + kdfparams.otherinfolen = strlen(otherinfo);
>
> Same for otherinfolen.
Sure. But note, otherinfo must support binary data. Thus, I think that the
kernel side must support a length parameter.
Here, for user space keyctl support, surely we have some limitation regarding
the support for binary data (i.e. the binary data must not contain a \0 as
strlen would return the wrong size).
>
> > + } else {
> > + kdfparams.kdfname = kdfname;
> > + kdfparams.kdfnamelen = strlen(kdfname);
> > + kdfparams.otherinfo = NULL;
> > + kdfparams.otherinfolen = 0;
> > + }
> > + ret = keyctl(KEYCTL_DH_COMPUTE, ¶ms, buf, buflen, &kdfparams);
> > + if (ret < 0) {
> > + free(buf);
> > + return -1;
> > + }
> > +
> > + buf[ret] = 0;
> > + *_buffer = buf;
> > + return ret;
> > +}
> > +
> > +/*
> >
> > * Depth-first recursively apply a function over a keyring tree
> > */
> >
> > static int recursive_key_scan_aux(key_serial_t parent, key_serial_t key,
> > diff --git a/keyutils.h b/keyutils.h
> > index b321aa8..5026270 100644
> > --- a/keyutils.h
> > +++ b/keyutils.h
> > @@ -108,6 +108,16 @@ struct keyctl_dh_params {
> >
> > key_serial_t base;
> >
> > };
> >
> > +struct keyctl_kdf_params {
> > +#define KEYCTL_KDF_MAX_OUTPUTLEN 1024 /* max length of KDF
> > output */ +#define KEYCTL_KDF_MAX_STRING_LEN 64 /* maximum
> > length of strings */
> It's better to leave this information out of the userspace as it may
> change depending on the kernel version. Let the kernel return an error if
> the lengths exceed limits.
Will do.
>
> > + char *kdfname;
> > + uint32_t kdfnamelen;
> > + char *otherinfo;
> > + uint32_t otherinfolen;
> > + uint32_t flags;
> > +};
> > +
> > /*
> >
> > * syscall wrappers
> > */
> >
> > @@ -172,6 +182,9 @@ extern int keyctl_read_alloc(key_serial_t id, void
> > **_buffer); extern int keyctl_get_security_alloc(key_serial_t id, char
> > **_buffer); extern int keyctl_dh_compute_alloc(key_serial_t private,
> > key_serial_t prime,>
> > key_serial_t base, void **_buffer);
> >
> > +int keyctl_dh_compute_kdf(key_serial_t private, key_serial_t prime,
> > + key_serial_t base, char *len, char *kdfname,
> > + char *otherinfo, void **_buffer);
> >
> > typedef int (*recursive_key_scanner_t)(key_serial_t parent, key_serial_t
> > key,>
> > char *desc, int desc_len, void *data);
> >
> > diff --git a/tests/keyctl/dh_compute/valid/runtest.sh
> > b/tests/keyctl/dh_compute/valid/runtest.sh index 40ec387..1c77268 100644
> > --- a/tests/keyctl/dh_compute/valid/runtest.sh
> > +++ b/tests/keyctl/dh_compute/valid/runtest.sh
> > @@ -80,6 +80,89 @@ marker "COMPUTE DH PUBLIC KEY"
> > dh_compute $privateid $primeid $generatorid
> > expect_payload payload $public
> >
> > +
> > +################################################################
> > +# Testing DH compute with KDF according to SP800-56A
> > +#
> > +# test vectors from
> > http://csrc.nist.gov/groups/STM/cavp/documents/keymgmt/KASTestVectorsFFC2
> > 014.zip +################################################################
> > +
> > +# SHA-256
> > +
> > +# XephemCAVS
> > +private="\x81\xb2\xc6\x5f\x5c\xba\xc0\x0b\x13\x53\xac\x38\xbd\x77\xa2\x5a
> > "
> > +private+="\x86\x50\xed\x48\x5e\x41\x3e\xac\x1d\x6c\x48\x85"
> > +
> > +# P
> > +prime="\xa3\xcc\x62\x23\xe5\x0c\x6e\x3f\x7b\xb0\x58\x1d\xcb\x9e\x9f\xf0"
> > +prime+="\x2c\x58\x07\x68\x32\x8a\x15\x20\x7b\x1c\x32\x31\x7f\xb7\x84\x96"
> > +prime+="\x81\x5e\x3c\xf7\xf9\xd0\x9c\xcb\x9f\xa8\x40\xff\x47\x98\x51\x1a"
> > +prime+="\x17\xb5\x59\x28\x72\x1e\x5d\xfb\xcc\xc5\x41\x47\xe0\xf0\x5f\x85"
> > +prime+="\xb3\xac\x41\x0b\x6a\xe3\xf5\x9b\x79\x6f\x3f\xea\xc7\xfc\x52\x49"
> > +prime+="\x21\x7e\xb2\xa0\x45\x88\x29\x3a\x5a\xde\x22\x78\x79\xf4\x6c\xeb"
> > +prime+="\x56\x45\x7b\x5c\x43\x12\x93\xe5\xe1\x04\xd1\xb9\x64\xbd\x2c\xdf"
> > +prime+="\xde\xff\xa0\x40\x49\xa9\x1e\x67\xee\x8c\x86\xe9\x44\xf0\x4f\x94"
> > +prime+="\x4a\x30\xe3\x61\xf8\xd1\x5d\x17\xe5\x01\x0c\xab\xb4\xef\x40\xc0"
> > +prime+="\xeb\xa5\xf4\xa2\x52\xd4\xfd\x6c\xf9\xda\xe6\x0e\x86\xe4\xb3\x00"
> > +prime+="\x9b\x1d\xfc\x92\x66\x70\x35\x72\x61\x58\x7a\xd0\x5c\x00\xa6\xc6"
> > +prime+="\xf0\x10\x6c\xec\x8f\xc5\x91\x31\x51\x50\x84\xa8\x70\x59\x41\x65"
> > +prime+="\xb4\x93\x90\xdb\x2d\x00\xe7\x53\x8f\x23\x0d\x53\x2f\x4a\x4e\xca"
> > +prime+="\x83\x09\xd7\x07\xc0\xb3\x83\x5c\xee\x04\xf3\xca\x55\x8a\x22\xc6"
> > +prime+="\xb5\x20\xfe\x25\xde\x6f\xfa\x90\xef\xda\x49\x27\xd0\x18\x59\x4c"
> > +prime+="\x0c\x0b\x77\x06\x73\x93\xb7\xf1\xe0\xfc\x7c\xf2\x16\xaf\xf3\x9f"
> > +
> > +# YephemIUT
> > +xa="\x9a\x70\x82\x2d\x3f\x06\x12\x3d\x0e\x51\x8e\xe1\x16\x51\xe5\xf6"
> > +xa+="\xb1\x19\xdc\x3b\x97\xd5\xb1\xc0\xa2\xa6\xf6\xde\x94\x25\x64\xba"
> > +xa+="\x10\x06\x1e\xec\xde\xb7\x36\x9c\xa5\x37\x49\x9e\x04\xb0\x36\xe9"
> > +xa+="\x7f\x44\x5a\x95\x6f\x63\x69\xae\x6e\x63\xfd\x27\xea\xe3\xe3\x47"
> > +xa+="\x85\x54\x47\xd3\xba\xc1\xc6\x0c\x10\xe7\x35\x07\x72\xc6\xc0\xc6"
> > +xa+="\xfb\xf9\xca\x3e\x38\xf0\xe8\x65\x88\x25\xd3\xb2\x0f\x1f\x02\x8f"
> > +xa+="\x35\xe3\x4d\x12\x35\x10\x3d\xf2\x33\x9b\x5b\x09\x9d\x3f\xe3\xe5"
> > +xa+="\x34\x6a\x69\x16\x42\xba\xc5\xb0\xbb\x03\xcd\x5d\x04\xd7\x56\x26"
> > +xa+="\x21\x49\x3f\xf1\xc4\x27\x3b\x6a\x45\xc5\xec\xb0\xb5\xe9\x08\xa0"
> > +xa+="\xf9\xf5\x62\x28\x2e\x85\x3e\xfc\x9a\x7e\xa1\x12\xe9\x47\x4f\xf6"
> > +xa+="\x94\x18\xf7\xc4\x7a\xe9\x66\xd4\x52\x4c\xa1\x70\x1b\x60\xa4\xbe"
> > +xa+="\x15\xc7\x5e\x27\xb4\x05\x80\x64\x68\x15\x6e\x02\xcb\xc5\x8f\xf4"
> > +xa+="\x66\x3c\x96\xac\x0c\x87\x36\x81\x35\xfa\x9b\x0b\xb6\x33\x7a\xe2"
> > +xa+="\x58\x52\x1d\x7d\x60\xc2\xa9\x1b\x4e\xd7\x72\xad\x65\x03\x40\x49"
> > +xa+="\x97\xf6\x79\x9d\xf6\x63\xa8\x99\x9c\xfd\x74\x7f\xa0\x67\xb9\x05"
> > +xa+="\x8a\xb3\x3b\xc1\x45\x94\x36\x6f\x28\xf5\xa2\xd9\x00\xb6\x46\x7a"
> > +
> > +# Z
> > +shared="0fdbd9a2 ebf50cba 489b4e4d 7cd6924a 42ee6324 a26988b2 22bc38e6
> > 9cc445f1\n" +shared+="eb47c1a4 62eca39f 39bcd7b8 19dede51 30bc38da
> > ec99c16f 40a4e5c1 9c97b796\n" +shared+="8b41823d a0650e37 13c73e6f
> > 5f2a9dff 2e67dbf5 40ee66f4 e694c28f ba1d604b\n" +shared+="71b57b8a
> > eeb67a35 ba425a38 490b6fb9 f713db22 6f893b7a 8962f426 ba3046fb\n"
> > +shared+="cff8538c 16f583e8 ae947672 0ba55ff9 75b440d0 c4565cc7 5837d23a
> > fea61a39\n" +shared+="e0b7f6c4 e24c2154 7eb19fce f8dbed10 b06a9cce
> > 971c0f0f ba7c1d5c b5035eaa\n" +shared+="4fddd3ba fe757339 e3321e3e
> > 4ebfe9e7 9c6c0401 4df63cf9 28d0a2c0 5b2d5521\n" +shared+="030c35f1
> > c84c97fe 64cad509 8012a003 d52d24c4 1a1f9348 b7575251 3facb02f\n" +
> > +# OI
> > +otherinfo="\xa1\xb2\xc3\xd4\xe5\x43\x41\x56\x53\x69\x64\x0d\x64\xc1\xb2"
> > +otherinfo+="\x33\x61\xb2\x61\xde\x78\x68\x8e\xa8\x65\xfc\xff\x11\x3c\x84"
> > +
> > +# DKM
> > +derived="8284e313 02c8a26b 393ec52d 9f9e0882\n"
> > +
> > +pcreate_key "-e $prime" user dh:prime @s
> > +expect_keyid primeid
> > +
> > +pcreate_key "-e $xa" user dh:xa @s
> > +expect_keyid xaid
> > +
> > +pcreate_key "-e $private" user dh:private @s
> > +expect_keyid privateid
> > +
> > +marker "COMPUTE DH SHARED SECRET"
> > +dh_compute $privateid $primeid $xaid
> > +expect_payload payload $shared
>
> As I mentioned at the top, we'll need an 'expect_multiline' function that
> handles values like $shared.
Ok.
>
> > +
> > +marker "COMPUTE DERIVED KEY FROM DH SHARED SECRET (SHA-256)"
> > +dh_compute $privateid $primeid $xaid 16 "kdf_ctr(sha256)" "$(echo -e -n
> > $otherinfo)" +expect_payload payload $derived
>
> Have you checked that expect_payload works correctly in this case? Seems
> like it should, since the output fits on one line.
I just tested it and the code does NOT catch the error. I.e. when changing
$derived, the harness still returns a PASS even though the returned data does
not match the expected data.
>
> > +
> > echo "++++ FINISHED TEST: $result" >>$OUTPUTFILE
> >
> > # --- then report the results in the database ---
>
> --
> Mat Martineau
> Intel OTC
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] DH support: add KDF handling support
From: Jeffrey Walton @ 2016-07-14 8:00 UTC (permalink / raw)
To: Stephan Mueller; +Cc: keyrings, linux-crypto
In-Reply-To: <1954976.nIU2Zma9Rk@tauon.atsec.com>
> Note, as shared secrets potentially post-processed by a KDF usually are again
> used as key or data encryption keys, they need to be truncated/expanded to a
> specific length anyway. A KDF inherently provides the truncation support to
> any arbitrary length. Thus, I would think that the caller needs to provide
> that length but does not need to truncate the output itself.
As far as I know, there's no reduction in proof that a truncated hash
is as secure as the non-truncated one. One of the reasons to provide
the output length as a security parameter is to help avoid truncation
and related hash output attacks.
Also see Kelsey's work on the subject;
http://www.google.com/search?q=nist+kelsey+truncated+hash.
Jeff
^ permalink raw reply
* [PATCH] crypto: rsa-pkcs1pad - Fix akcipher request allocation
From: Salvatore Benedetto @ 2016-07-14 10:25 UTC (permalink / raw)
To: herbert, davem, andrew.zaborowski; +Cc: linux-crypto, Salvatore Benedetto
Embedding the akcipher_request in pkcs1pad_request don't take
into account the context space required by the akcipher object.
This result in memory corruption (and kernel panic) as the
akcipher object will overwrite anything after akcipher_request
structure.
Fix it by dinamically allocating the structure with akcipher_request_alloc.
Software akcipher implementation is working only because it is
synchronous and it does not use a request context.
Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
---
crypto/rsa-pkcs1pad.c | 75 ++++++++++++++++++++++++++++++++++-----------------
1 file changed, 51 insertions(+), 24 deletions(-)
diff --git a/crypto/rsa-pkcs1pad.c b/crypto/rsa-pkcs1pad.c
index 880d3db..d663ab6 100644
--- a/crypto/rsa-pkcs1pad.c
+++ b/crypto/rsa-pkcs1pad.c
@@ -101,7 +101,7 @@ struct pkcs1pad_inst_ctx {
};
struct pkcs1pad_request {
- struct akcipher_request child_req;
+ struct akcipher_request *child_req;
struct scatterlist in_sg[2], out_sg[1];
uint8_t *in_buf, *out_buf;
@@ -192,7 +192,7 @@ static int pkcs1pad_encrypt_sign_complete(struct akcipher_request *req, int err)
if (err)
goto out;
- len = req_ctx->child_req.dst_len;
+ len = req_ctx->child_req->dst_len;
pad_len = ctx->key_size - len;
/* Four billion to one */
@@ -215,6 +215,7 @@ out:
req->dst_len = ctx->key_size;
kfree(req_ctx->in_buf);
+ akcipher_request_free(req_ctx->child_req);
return err;
}
@@ -277,15 +278,21 @@ static int pkcs1pad_encrypt(struct akcipher_request *req)
pkcs1pad_sg_set_buf(req_ctx->out_sg, req_ctx->out_buf,
ctx->key_size, NULL);
- akcipher_request_set_tfm(&req_ctx->child_req, ctx->child);
- akcipher_request_set_callback(&req_ctx->child_req, req->base.flags,
+ req_ctx->child_req = akcipher_request_alloc(ctx->child, GFP_KERNEL);
+ if (!req_ctx->child_req) {
+ kfree(req_ctx->out_buf);
+ kfree(req_ctx->in_buf);
+ return -ENOMEM;
+ }
+ akcipher_request_set_tfm(req_ctx->child_req, ctx->child);
+ akcipher_request_set_callback(req_ctx->child_req, req->base.flags,
pkcs1pad_encrypt_sign_complete_cb, req);
/* Reuse output buffer */
- akcipher_request_set_crypt(&req_ctx->child_req, req_ctx->in_sg,
+ akcipher_request_set_crypt(req_ctx->child_req, req_ctx->in_sg,
req->dst, ctx->key_size - 1, req->dst_len);
- err = crypto_akcipher_encrypt(&req_ctx->child_req);
+ err = crypto_akcipher_encrypt(req_ctx->child_req);
if (err != -EINPROGRESS &&
(err != -EBUSY ||
!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
@@ -308,7 +315,7 @@ static int pkcs1pad_decrypt_complete(struct akcipher_request *req, int err)
if (err)
goto done;
- if (req_ctx->child_req.dst_len != ctx->key_size - 1) {
+ if (req_ctx->child_req->dst_len != ctx->key_size - 1) {
err = -EINVAL;
goto done;
}
@@ -317,18 +324,18 @@ static int pkcs1pad_decrypt_complete(struct akcipher_request *req, int err)
err = -EINVAL;
goto done;
}
- for (pos = 1; pos < req_ctx->child_req.dst_len; pos++)
+ for (pos = 1; pos < req_ctx->child_req->dst_len; pos++)
if (req_ctx->out_buf[pos] == 0x00)
break;
- if (pos < 9 || pos == req_ctx->child_req.dst_len) {
+ if (pos < 9 || pos == req_ctx->child_req->dst_len) {
err = -EINVAL;
goto done;
}
pos++;
- if (req->dst_len < req_ctx->child_req.dst_len - pos)
+ if (req->dst_len < req_ctx->child_req->dst_len - pos)
err = -EOVERFLOW;
- req->dst_len = req_ctx->child_req.dst_len - pos;
+ req->dst_len = req_ctx->child_req->dst_len - pos;
if (!err)
sg_copy_from_buffer(req->dst,
@@ -337,6 +344,7 @@ static int pkcs1pad_decrypt_complete(struct akcipher_request *req, int err)
done:
kzfree(req_ctx->out_buf);
+ akcipher_request_free(req_ctx->child_req);
return err;
}
@@ -373,16 +381,22 @@ static int pkcs1pad_decrypt(struct akcipher_request *req)
pkcs1pad_sg_set_buf(req_ctx->out_sg, req_ctx->out_buf,
ctx->key_size, NULL);
- akcipher_request_set_tfm(&req_ctx->child_req, ctx->child);
- akcipher_request_set_callback(&req_ctx->child_req, req->base.flags,
+ req_ctx->child_req = akcipher_request_alloc(ctx->child, GFP_KERNEL);
+ if (!req_ctx->child_req) {
+ kfree(req_ctx->out_buf);
+ return -ENOMEM;
+ }
+
+ akcipher_request_set_tfm(req_ctx->child_req, ctx->child);
+ akcipher_request_set_callback(req_ctx->child_req, req->base.flags,
pkcs1pad_decrypt_complete_cb, req);
/* Reuse input buffer, output to a new buffer */
- akcipher_request_set_crypt(&req_ctx->child_req, req->src,
+ akcipher_request_set_crypt(req_ctx->child_req, req->src,
req_ctx->out_sg, req->src_len,
ctx->key_size);
- err = crypto_akcipher_decrypt(&req_ctx->child_req);
+ err = crypto_akcipher_decrypt(req_ctx->child_req);
if (err != -EINPROGRESS &&
(err != -EBUSY ||
!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
@@ -420,6 +434,12 @@ static int pkcs1pad_sign(struct akcipher_request *req)
if (!req_ctx->in_buf)
return -ENOMEM;
+ req_ctx->child_req = akcipher_request_alloc(ctx->child, GFP_KERNEL);
+ if (!req_ctx->child_req) {
+ kfree(req_ctx->in_buf);
+ return -ENOMEM;
+ }
+
ps_end = ctx->key_size - digest_size - req->src_len - 2;
req_ctx->in_buf[0] = 0x01;
memset(req_ctx->in_buf + 1, 0xff, ps_end - 1);
@@ -431,15 +451,15 @@ static int pkcs1pad_sign(struct akcipher_request *req)
pkcs1pad_sg_set_buf(req_ctx->in_sg, req_ctx->in_buf,
ctx->key_size - 1 - req->src_len, req->src);
- akcipher_request_set_tfm(&req_ctx->child_req, ctx->child);
- akcipher_request_set_callback(&req_ctx->child_req, req->base.flags,
+ akcipher_request_set_tfm(req_ctx->child_req, ctx->child);
+ akcipher_request_set_callback(req_ctx->child_req, req->base.flags,
pkcs1pad_encrypt_sign_complete_cb, req);
/* Reuse output buffer */
- akcipher_request_set_crypt(&req_ctx->child_req, req_ctx->in_sg,
+ akcipher_request_set_crypt(req_ctx->child_req, req_ctx->in_sg,
req->dst, ctx->key_size - 1, req->dst_len);
- err = crypto_akcipher_sign(&req_ctx->child_req);
+ err = crypto_akcipher_sign(req_ctx->child_req);
if (err != -EINPROGRESS &&
(err != -EBUSY ||
!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
@@ -464,7 +484,7 @@ static int pkcs1pad_verify_complete(struct akcipher_request *req, int err)
goto done;
err = -EINVAL;
- dst_len = req_ctx->child_req.dst_len;
+ dst_len = req_ctx->child_req->dst_len;
if (dst_len < ctx->key_size - 1)
goto done;
@@ -507,6 +527,7 @@ static int pkcs1pad_verify_complete(struct akcipher_request *req, int err)
out_buf + pos, req->dst_len);
done:
kzfree(req_ctx->out_buf);
+ akcipher_request_free(req_ctx->child_req);
return err;
}
@@ -551,16 +572,22 @@ static int pkcs1pad_verify(struct akcipher_request *req)
pkcs1pad_sg_set_buf(req_ctx->out_sg, req_ctx->out_buf,
ctx->key_size, NULL);
- akcipher_request_set_tfm(&req_ctx->child_req, ctx->child);
- akcipher_request_set_callback(&req_ctx->child_req, req->base.flags,
+ req_ctx->child_req = akcipher_request_alloc(ctx->child, GFP_KERNEL);
+ if (!req_ctx->child_req) {
+ kfree(req_ctx->out_buf);
+ return -ENOMEM;
+ }
+
+ akcipher_request_set_tfm(req_ctx->child_req, ctx->child);
+ akcipher_request_set_callback(req_ctx->child_req, req->base.flags,
pkcs1pad_verify_complete_cb, req);
/* Reuse input buffer, output to a new buffer */
- akcipher_request_set_crypt(&req_ctx->child_req, req->src,
+ akcipher_request_set_crypt(req_ctx->child_req, req->src,
req_ctx->out_sg, req->src_len,
ctx->key_size);
- err = crypto_akcipher_verify(&req_ctx->child_req);
+ err = crypto_akcipher_verify(req_ctx->child_req);
if (err != -EINPROGRESS &&
(err != -EBUSY ||
!(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] DH support: add KDF handling support
From: Stephan Mueller @ 2016-07-14 14:19 UTC (permalink / raw)
To: noloader; +Cc: keyrings, linux-crypto
In-Reply-To: <CAH8yC8=GUqm5w069_42SWpjTwcuQxvmCtrAfzX9BnoyW_PEYwA@mail.gmail.com>
Am Donnerstag, 14. Juli 2016, 04:00:57 schrieb Jeffrey Walton:
Hi Jeffrey,
> > Note, as shared secrets potentially post-processed by a KDF usually are
> > again used as key or data encryption keys, they need to be
> > truncated/expanded to a specific length anyway. A KDF inherently provides
> > the truncation support to any arbitrary length. Thus, I would think that
> > the caller needs to provide that length but does not need to truncate the
> > output itself.
>
> As far as I know, there's no reduction in proof that a truncated hash
> is as secure as the non-truncated one. One of the reasons to provide
> the output length as a security parameter is to help avoid truncation
> and related hash output attacks.
>
> Also see Kelsey's work on the subject;
> http://www.google.com/search?q=nist+kelsey+truncated+hash.
I understand that point. However, a KDF is not just a simple hash or
truncation thereof. Furthermore, Kelsey is part of the NIST team that also
developed SP800-108 (the KDF definition). Furthermore, the authors of
SP800-56A (in particular Allen Roginsky who I met personally a number of
times) work closely with Kelsey too.
So, I would not think that applying the standard KDF operation which is
intended to "right-size" the DH output is nothing we should worry about.
I would rather worry about the size of the private key in the DH operation.
The private key should be as small as cryptographically possible (e.g. 224 or
256 bits) instead of half of the DH public key minus one (what TLS does) due
to the reduced number of Sopie-Germain primes that are available in the latter
case.
Ciao
Stephan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox