Hi Ard,
On Tue, Nov 03, 2020 at 05:28:09PM +0100, Ard Biesheuvel wrote:
> @@ -42,24 +42,24 @@ static void chacha_doneon(u32 *state, u8 *dst, const u8
> *src,
> {
> u8 buf[CHACHA_BLOCK_SIZE];
>
> - while (bytes >= CHACHA_BLOCK_SIZE * 4) {
> - chacha_4block_xor_neon(state,
On 11/12/2020 21:00, Peter Zijlstra wrote:
> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
>> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
>> On platforms with Zhaoxin CPUs supporting this X86 feature, When
>> crc32c-intel and crc32c-generic are both registere
On Fri, Dec 11, 2020 at 01:27:15PM +0100, Ard Biesheuvel wrote:
> The cipher routines in the crypto API are mostly intended for templates
> implementing skcipher modes generically in software, and shouldn't be
> used outside of the crypto subsystem. So move the prototypes and all
> related definiti
On Fri, Dec 11, 2020 at 01:27:14PM +0100, Ard Biesheuvel wrote:
> Allocating a cipher via the crypto API only to free it again after using
> it to encrypt a single block is unnecessary in cases where the algorithm
> is known at compile time. So replace this pattern with a call to the AES
> library.
From: Mickaël Salaün
Add and use a check-blacklist-hashes.awk script to make sure that the
builtin blacklist hashes will be approved by the run time blacklist
description checks. This is useful to debug invalid hash formats, and
it make sure that previous hashes which could have been loaded in t
From: Mickaël Salaün
Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user
to dynamically add new keys to the blacklist keyring. This enables to
invalidate new certificates, either from being loaded in a keyring, or
from being trusted in a PKCS#7 certificate chain. This also
From: Mickaël Salaün
Factor out the blacklist hash creation with the get_raw_hash() helper.
This also centralize the "tbs" and "bin" prefixes and make them private,
which help to manage them consistently.
Cc: David Howells
Cc: David S. Miller
Cc: David Woodhouse
Cc: Herbert Xu
Cc: Jarkko Sak
Hi,
This second patch series includes some minor fixes and remove the 4 fix
patches picked by David Howells. This patch series can then be applied
on top of
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
The goal of these patches is to add a new configura
From: Mickaël Salaün
Before exposing this new key type to user space, make sure that only
meaningful blacklisted hashes are accepted. This is also checked for
builtin blacklisted hashes, but a following commit make sure that the
user will notice (at built time) and will fix the configuration if
From: Mickaël Salaün
Add a new helper print-cert-tbs-hash.sh to generate a TBSCertificate
hash from a given certificate. This is useful to generate a blacklist
key description used to forbid loading a specific certificate in a
keyring, or to invalidate a certificate provided by a PKCS#7 file.
C
On 04/12/2020 15:09, David Howells wrote:
> Mickaël Salaün wrote:
>
>> +if (*desc)
>> +/* The hash is greater than MAX_HASH_LEN. */
>> +return -EINVAL;
>
> -ENOPKG might be better. It's not that the string is invalid, it's just that
> it's unsupported at the momen
On 09/12/2020 12:58, David Howells wrote:
> Mickaël Salaün wrote:
>
>> + cmd_check_blacklist_hashes = $(AWK) -f
>> scripts/check-blacklist-hashes.awk $(2); touch $@
>
> The script name needs prefixing with $(srctree)/ so that it can be used with
> alternative build directories.
Right
>
On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> On platforms with Zhaoxin CPUs supporting this X86 feature, When
> crc32c-intel and crc32c-generic are both registered, system will
> use crc32c-intel because its .c
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
>
> +/* curve25519 */
> +static u64 curve25519_g_x[] = { 0x0009, 0x,
> + 0x, 0x };
> +static u64 curve25519_p[] = { 0xffed, 0xfff
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
>
> +/* size in bytes of the n prime */
> +#define HPRE_ECC_NIST_P128_N_SIZE 16
Do we truly need P-128? Besides, I do not see that curve being defined in
contemporary cipher specs.
> +#define HPRE_ECC_NIST_P192_N_SIZE 24
> +#defi
Meng,
It looks like not just definitions but some static data is moved to
includes. Why?
Thanks,
On Fri, Dec 11, 2020 at 02:30:32PM +0800, Meng Yu wrote:
> Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
> so all can use it,
>
> Signed-off-by: Meng Yu
> Reviewed-by: Zaibo
On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> On platforms with Zhaoxin CPUs supporting this X86 feature, When
> crc32c-intel and crc32c-generic are both registered, system will
> use crc32c-intel because its .c
Patch #2 puts the cipher API (which should not be used outside of the
crypto API implementation) into an internal header file and module
namespace
Patch #1 is a prerequisite for this, to avoid having to make the chelsio
driver import the crypto internal namespace.
Changes since v1:
- add missing
Allocating a cipher via the crypto API only to free it again after using
it to encrypt a single block is unnecessary in cases where the algorithm
is known at compile time. So replace this pattern with a call to the AES
library.
Cc: Ayush Sawal
Cc: Vinay Kumar Yadav
Cc: Rohit Maheshwari
Signed-o
The cipher routines in the crypto API are mostly intended for templates
implementing skcipher modes generically in software, and shouldn't be
used outside of the crypto subsystem. So move the prototypes and all
related definitions to a new header file under include/crypto/internal.
Also, let's use
The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
On platforms with Zhaoxin CPUs supporting this X86 feature, When
crc32c-intel and crc32c-generic are both registered, system will
use crc32c-intel because its .cra_priority is greater than
crc32c-generic. This case expect to use crc3
On Fri, Dec 11, 2020 at 12:51:46PM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 12:14:24PM +, David Howells wrote:
> >
> > Hi Jarkko,
> >
> > I've extended my collection of minor keyrings fixes for the next merge
> > window. Anything else I should add (or anything I should drop)?
On Tue, Dec 01, 2020 at 02:24:48PM +, Giovanni Cabiddu wrote:
> This set adds support for AES-CTR and AES-XTS for QAT GEN4 devices and
> adds logic to detect and enable crypto capabilities in the qat_4xxx
> driver.
>
> Marco Chiappero (3):
> crypto: qat - add AES-CTR support for QAT GEN4 dev
On Fri, Dec 11, 2020 at 11:42:08AM +0100, Ard Biesheuvel wrote:
>
> I think this is a valid use of a bare cipher - it lives as long as the
> TFM itself, and may be used on a hot path.
>
> I need to respin the bare cipher change I sent the other day anyway,
> so I'll make sure this driver gets the
On Wed, Dec 09, 2020 at 12:14:24PM +, David Howells wrote:
>
> Hi Jarkko,
>
> I've extended my collection of minor keyrings fixes for the next merge
> window. Anything else I should add (or anything I should drop)?
>
> The patches can be found on the following branch:
>
>
> https://
On Fri, 11 Dec 2020 at 11:07, Herbert Xu wrote:
>
> On Tue, Dec 01, 2020 at 02:24:50PM +, Giovanni Cabiddu wrote:
> >
> > @@ -1293,6 +1366,12 @@ static int qat_alg_skcipher_init_xts_tfm(struct
> > crypto_skcipher *tfm)
> > if (IS_ERR(ctx->ftfm))
> > return PTR_ERR(ctx->ftf
On Tue, Dec 01, 2020 at 02:50:18PM +0800, Yejune Deng wrote:
> a set of atomic_inc_return() looks more neater
>
> Signed-off-by: Yejune Deng
> ---
> drivers/crypto/hisilicon/trng/trng.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu
On Fri, Dec 04, 2020 at 12:20:04AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The bitreverse helper is almost always built into the kernel,
> but in a rare randconfig build it is possible to hit a case
> in which it is a loadable module while the atmel-i2c driver
> is built-in:
>
> ar
On Thu, Nov 26, 2020 at 11:51:46AM +, Daniele Alessandrelli wrote:
> The Intel Keem Bay SoC has an Offload Crypto Subsystem (OCS) featuring a
> crypto engine for accelerating AES/SM4 operations.
>
> This driver adds support for such hardware thus enabling hardware
> acceleration for the follow
On Thu, Dec 10, 2020 at 10:28:35AM +0200, Horia Geantă wrote:
>
> Moving the memory allocations from caam driver into the generic crypto API
> has the side effect of dropping the GFP_DMA allocation flag.
>
> For cases when caam device is limited to 32-bit address space and
> there's no IOMMU, this
On Tue, Dec 01, 2020 at 02:24:50PM +, Giovanni Cabiddu wrote:
>
> @@ -1293,6 +1366,12 @@ static int qat_alg_skcipher_init_xts_tfm(struct
> crypto_skcipher *tfm)
> if (IS_ERR(ctx->ftfm))
> return PTR_ERR(ctx->ftfm);
>
> + ctx->tweak = crypto_alloc_cipher("aes", 0, 0);
On Wed, Dec 09, 2020 at 12:14:24PM +, David Howells wrote:
>
> Hi Jarkko,
>
> I've extended my collection of minor keyrings fixes for the next merge
> window. Anything else I should add (or anything I should drop)?
Looks good to me. I dropped the keys fixes that I had previously in
my tree
32 matches
Mail list logo
