1. Enable 'ECDH' algorithm in Kunpeng 930;
2. HPRE ECDH Support ECC curve: P192, P224, P256, P384, P521.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 2 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 493 +++-
drivers
From: Hui Tang
HPRE of Kunpeng 930 is updated on cluster numbers and configurations
of Kunpeng 920 HPRE, so we try to update this driver to make it running
okay on both chips.
Signed-off-by: Hui Tang
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h |
1. Add ecc curves(P224, P384, P521) for ECDH;
2. Reorder ECC 'Curves ID' in 'include/crypto/ecdh.h', and
modify 'curve_id' used in 'testmgr.h';
3. Add function 'ecc_get_curve_param' in 'include/crypto/ecc_curve.h' for
users, so everyone in the kernel tree can easily get ecc curve params;
Sig
1. Add curve 25519 parameters;
2. Add curve25519 function 'ecc_get_curve25519_param',
to be exposed to everyone in kernel tree.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c | 7 +++
crypto/ecc_curve_defs.h| 17 +
include/crypto/ecc_curv
1. Add some new elliptic curve parameters definitions, and reorder
ECC 'Curves IDs';
2. Add interface to get elliptic curve by curve_id in
"include/crypto/ecc_curve.h" by curve_id;
3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930.
v6->v7:
- patch #4: add function interface to ex
Enable 'CURVE25519' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/Kconfig| 1 +
drivers/crypto/hisilicon/hpre/hpre.h| 2 +
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 370 +++-
3 files change
A new generation of accelerator Kunpeng930 has appeared, and the
corresponding driver needs to be updated to support some new
algorithms of Kunpeng930. To be compatible with Kunpeng920, we
add parameter 'struct hisi_qm *qm' to sec_algs_(un)register to
identify the chip's version.
Signed-off-by: Me
Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
drivers/crypto/hisilicon/hpre/hpr
On Sat, Jan 16, 2021 at 05:48:08PM +0100, Ard Biesheuvel wrote:
> My recent patches to the AES-NI driver addressed all the instances of
> indirect calls occurring in the XTS and GCM drivers, and while at it,
> limited the scope of FPU enabled/preemption disabled regions not to
> cover the work that
On Fri, Jan 15, 2021 at 10:46:05PM +0200, Ovidiu Panait wrote:
> src_size and aad_size are defined as u32, so the following expressions are
> currently being evaluated using 32-bit arithmetic:
>
> bit_len = src_size * 8;
> ...
> bit_len = aad_size * 8;
>
> However, bit_len is used afterwards in a
On Fri, Jan 15, 2021 at 08:30:12PM +0100, Jason A. Donenfeld wrote:
> With no mod_exit function, users are unable to unload the module after
> use. I'm not aware of any reason why module unloading should be
> prohibited for this one, so this commit simply adds an empty exit
> function.
>
> Reporte
On Fri, Jan 15, 2021 at 07:22:18PM +0530, Srujana Challa wrote:
> This series introduces crypto(CPT) drivers(PF & VF) for Marvell
> OcteonTX2 CN96XX Soc.
>
> OcteonTX2 SOC's resource virtualization unit (RVU) supports multiple
> physical and virtual functions. Each of the PF/VF's functionality is
On Wed, Jan 13, 2021 at 10:11:35AM +0100, Ard Biesheuvel wrote:
> Unlike many other structure types defined in the crypto API, the
> 'shash_desc' structure is permitted to live on the stack, which
> implies its contents may not be accessed by DMA masters. (This is
> due to the fact that the stack m
On Thu, Jan 14, 2021 at 07:10:10PM +0100, Ard Biesheuvel wrote:
> The accelerated, instruction based implementations of SHA1, SHA2 and
> SHA3 are autoloaded based on CPU capabilities, given that the code is
> modest in size, and widely used, which means that resolving the algo
> name, loading all c
On Thu, Jan 21, 2021 at 04:13:51PM +, Alessandrelli, Daniele wrote:
>
> As expected, the second implementation does not pass self-tests and
> crypto_alloc_kpp() returns -ELIBBAD when trying to allocate it, but
> I've seen that I can avoid the error (and have it allocated properly)
> by passing
On Thu, Jan 21 2021 at 1:09pm -0500,
Ard Biesheuvel wrote:
> On Thu, 21 Jan 2021 at 19:05, Eric Biggers wrote:
> >
> > On Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
> > > Salsa20 is not used anywhere in the kernel, is not suitable for disk
> > > encryption, and widely consider
On 21/01/2021 19:09, Ard Biesheuvel wrote:
> On Thu, 21 Jan 2021 at 19:05, Eric Biggers wrote:
>>
>> On Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
>>> Salsa20 is not used anywhere in the kernel, is not suitable for disk
>>> encryption, and widely considered to have been supersede
On Thu, 21 Jan 2021 at 19:05, Eric Biggers wrote:
>
> On Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
> > Salsa20 is not used anywhere in the kernel, is not suitable for disk
> > encryption, and widely considered to have been superseded by ChaCha20.
> > So let's remove it.
> >
> >
On Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
> Salsa20 is not used anywhere in the kernel, is not suitable for disk
> encryption, and widely considered to have been superseded by ChaCha20.
> So let's remove it.
>
> Signed-off-by: Ard Biesheuvel
> ---
> Documentation/admin-guid
From: David Howells
KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or
key_alloc(), as these only take KEY_ALLOC_* flags. KEY_FLAG_KEEP has
the same value as KEY_ALLOC_BYPASS_RESTRICTION, but fortunately only
key_create_or_update() uses it. LSMs using the key_alloc hook don't
check t
From: Mickaël Salaün
Use GLOBAL_ROOT_UID and GLOBAL_ROOT_GID definitions, and add appropriate
include files.
Cc: David Woodhouse
Signed-off-by: Mickaël Salaün
Signed-off-by: David Howells
---
Changes since v2:
* Cherry-pick v1 patch from
https://lore.kernel.org/lkml/2659836.1607940...@wart
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: Alex Shi
certs/blacklist.c:84: warning: Function parameter or member 'hash' not
described in 'mark_hash_blacklisted'
Cc: David Woodhouse
Cc: keyri...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Alex Shi
Signed-off-by: David Howells
Reviewed-by: Ben Boeckel
Signed-of
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
Signed-off-by:
From: Mickaël Salaün
Add missing linux/types.h for size_t.
[DH: Changed from stddef.h]
Signed-off-by: Mickaël Salaün
Signed-off-by: David Howells
Reviewed-by: Ben Boeckel
Reviewed-by: Jarkko Sakkinen
---
Changes since v3:
* Add Reviewed-by Jarkko Sakkinen.
Changes since v2:
* Cherry-pick
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
On Thu, 2021-01-21 at 10:52 +0100, Ard Biesheuvel wrote:
> On Wed, 20 Jan 2021 at 20:00, Alessandrelli, Daniele
> wrote:
> > Hi Ard,
> >
> > Thank you very much for your valuable feedback.
> >
> > On Mon, 2021-01-18 at 13:09 +0100, Ard Biesheuvel wrote:
> > > This is rather unusual compared with
This fourth patch series mainly reorder patches and add more
documentation as requested by Jarkko. This series is based on
v5.11-rc4.
The goal of these patches is to add a new configuration option to enable the
root user to load signed keys in the blacklist keyring. This keyring is useful
to "un
From: Mickaël Salaün
When looking for a blacklisted hash, bin2hex() is used to transform a
binary hash to an ascii (lowercase) hexadecimal string. This string is
then search for in the description of the keys from the blacklist
keyring. When adding a key to the blacklist keyring,
blacklist_vet_
From: Mickaël Salaün
Add and use a check-blacklist-hashes.awk script to make sure that the
builtin blacklist hashes set with CONFIG_SYSTEM_BLACKLIST_HASH_LIST will
effectively be taken into account as blacklisted hashes. This is useful
to debug invalid hash formats, and it make sure that previou
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.
T
On Thu, Jan 21, 2021 at 04:32:26PM +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 21, 2021 at 12:23:53PM +0800, joeyli wrote:
> > Hi Jarkko,
> >
> > On Thu, Jan 21, 2021 at 01:40:48AM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Jan 20, 2021 at 05:05:14PM +0800, Lee, Chun-Yi wrote:
> > > > This patch
On Thu, Jan 21, 2021 at 10:18:20AM +0100, Mickaël Salaün wrote:
>
> On 21/01/2021 00:53, Jarkko Sakkinen wrote:
> > On Wed, Jan 20, 2021 at 12:57:55PM +0100, Mickaël Salaün wrote:
> >>
> >> On 20/01/2021 06:19, Jarkko Sakkinen wrote:
> >>> On Thu, Jan 14, 2021 at 04:19:07PM +0100, Mickaël Salaün w
On Thu, Jan 21, 2021 at 12:23:53PM +0800, joeyli wrote:
> Hi Jarkko,
>
> On Thu, Jan 21, 2021 at 01:40:48AM +0200, Jarkko Sakkinen wrote:
> > On Wed, Jan 20, 2021 at 05:05:14PM +0800, Lee, Chun-Yi wrote:
> > > This patch adds the logic for parsing the CodeSign extended key usage
> > > extension in
Salsa20 is not used anywhere in the kernel, is not suitable for disk
encryption, and widely considered to have been superseded by ChaCha20.
So let's remove it.
Signed-off-by: Ard Biesheuvel
---
Documentation/admin-guide/device-mapper/dm-integrity.rst |4 +-
crypto/Kconfig
Tiger is never referenced anywhere in the kernel, and unlikely
to be depended upon by userspace via AF_ALG. So let's remove it.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 13 -
crypto/Makefile | 1 -
crypto/tcrypt.c | 36 --
crypto/testmgr.c | 18 -
crypto/testmgr.h | 126
RIPE-MD 320 is never referenced anywhere in the kernel, and unlikely
to be depended upon by userspace via AF_ALG. So let's remove it
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 12 -
crypto/ripemd.h | 8 -
crypto/rmd320.c | 391
crypto/tcrypt.c | 14 +-
crypt
RIPE-MD 128 is never referenced anywhere in the kernel, and unlikely
to be depended upon by userspace via AF_ALG. So let's remove it.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 13 -
crypto/Makefile | 1 -
crypto/ripemd.h | 3 -
crypto/rmd128.c | 323
crypt
RIPE-MD 256 is never referenced anywhere in the kernel, and unlikely
to be depended upon by userspace via AF_ALG. So let's remove it
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 12 -
crypto/Makefile | 1 -
crypto/ripemd.h | 3 -
crypto/rmd256.c | 342
crypto
Remove a set of algorithms that are never used in the kernel, and are
highly unlikely to be depended upon by user space either.
Cc: Eric Biggers
Cc: Herbert Xu
Ard Biesheuvel (5):
crypto: remove RIPE-MD 128 hash algorithm
crypto: remove RIPE-MD 256 hash algorithm
crypto: remove RIPE-MD 32
Le 21/01/2021 à 11:02, Ard Biesheuvel a écrit :
On Thu, 21 Jan 2021 at 10:54, Christophe Leroy
wrote:
Le 21/01/2021 à 08:31, Ard Biesheuvel a écrit :
On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
wrote:
Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
On Wed, 20 Jan 2021 at 19:59,
On Thu, 21 Jan 2021 at 10:54, Christophe Leroy
wrote:
>
>
>
> Le 21/01/2021 à 08:31, Ard Biesheuvel a écrit :
> > On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
> > wrote:
> >>
> >>
> >>
> >> Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
> >>> On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
> >>
Le 21/01/2021 à 08:31, Ard Biesheuvel a écrit :
On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
wrote:
Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
wrote:
Talitos Security Engine AESU considers any input
data size that is not a multiple
On Wed, 20 Jan 2021 at 20:00, Alessandrelli, Daniele
wrote:
>
> Hi Ard,
>
> Thank you very much for your valuable feedback.
>
> On Mon, 2021-01-18 at 13:09 +0100, Ard Biesheuvel wrote:
> > This is rather unusual compared with how the crypto API is typically
> > used, but if this is really what you
On 21/01/2021 00:53, Jarkko Sakkinen wrote:
> On Wed, Jan 20, 2021 at 12:57:55PM +0100, Mickaël Salaün wrote:
>>
>> On 20/01/2021 06:19, Jarkko Sakkinen wrote:
>>> On Thu, Jan 14, 2021 at 04:19:07PM +0100, Mickaël Salaün wrote:
From: Mickaël Salaün
Add and use a check-blacklist-ha
45 matches
Mail list logo
