This patch adds the logic for parsing the CodeSign extended key usage
extension in X.509. The parsing result will be set to the eku flag
which is carried by public key. It can be used in the PKCS#7
verification.
Signed-off-by: "Lee, Chun-Yi"
---
crypto/asymmetric_keys/x509_cert_parser.c | 24 +++
NIAP PP_OS certification requests that the OS shall validate the
CodeSigning extended key usage extension field for integrity
verifiction of exectable code:
https://www.niap-ccevs.org/MMO/PP/-442-/
FIA_X509_EXT.1.1
This patchset adds the logic for parsing the codeSigning EKU extension
Add an openssl command option example for generating CodeSign extended
key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled.
Signed-off-by: "Lee, Chun-Yi"
---
Documentation/admin-guide/module-signing.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/
This patch adds the logic for checking the CodeSigning extended
key usage when verifying signature of kernel module or
kexec PE binary in PKCS#7.
Signed-off-by: "Lee, Chun-Yi"
---
certs/system_keyring.c | 2 +-
crypto/asymmetric_keys/Kconfig | 9 +
crypto/asymmetric
Add codeSigning EKU to the X.509 key generation config for the build time
autogenerated kernel key.
Signed-off-by: "Lee, Chun-Yi"
---
certs/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/certs/Makefile b/certs/Makefile
index f4c25b67aad9..1ef4d6ca43b7 100644
--- a/certs/Makefile
++
On Wed, Jan 20, 2021 at 04:40:45PM +1100, Herbert Xu wrote:
> On Wed, Jan 20, 2021 at 04:26:29PM +1100, Herbert Xu wrote:
> >
> > Is your machine big-endian or little-endian?
>
> Does this patch fix your problem?
Yes, it fixes the problem and also the failing hash test.
Thanks and best
Sven
>
On 20/01/2021 04:43, Jarkko Sakkinen wrote:
> On Thu, Jan 14, 2021 at 04:19:01PM +0100, Mickaël Salaün wrote:
>> 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 sea
On 20/01/2021 06:15, Jarkko Sakkinen wrote:
> On Thu, Jan 14, 2021 at 04:19:04PM +0100, Mickaël Salaün wrote:
>> From: Mickaël Salaün
>>
>> Align with the new macros and add appropriate include files.
>>
>> Cc: David Woodhouse
>> Signed-off-by: Mickaël Salaün
>> Signed-off-by: David Howells
>
On 20/01/2021 06:23, Jarkko Sakkinen wrote:
> On Thu, Jan 14, 2021 at 04:19:08PM +0100, Mickaël Salaün wrote:
>> 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
>> invali
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-hashes.awk script to make sure that the
>> builtin blacklist hashes will be approved by the run time blacklist
>> description
On Fri, Jan 15, 2021 at 09:49:02AM -0700, Eric Snowberg wrote:
>
> > On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
> >
> > On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrote:
> >>
> >>> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
> >>> wrote:
> >>>
> >>> On Tue, Jan 12, 202
On 20/01/2021 05:16, Jarkko Sakkinen wrote:
> On Thu, Jan 14, 2021 at 04:19:05PM +0100, Mickaël Salaün wrote:
>> 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 bla
On 20/01/2021 04:55, Jarkko Sakkinen wrote:
> On Thu, Jan 14, 2021 at 04:19:03PM +0100, Mickaël Salaün wrote:
>> 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
>> K
On 1/17/21 4:16 AM, Domen Stangar wrote:
Sorry for late answer, somewhat missed mail.
dmesg last lines that where added
[ 325.691756] ccp :0a:00.2: enabling device ( -> 0002)
[ 325.692217] ccp :0a:00.2: ccp enabled
[ 325.702401] ccp :0a:00.2: tee enabled
[ 325.702405] ccp 00
On Tue, Jan 19, 2021 at 05:29:05PM +0100, Ard Biesheuvel wrote:
> On Tue, 19 Jan 2021 at 17:01, Dave Martin wrote:
> >
> > On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> > > Kernel mode NEON can be used in task or softirq context, but only in
> > > a non-nesting manner, i.e., so
On Tue, Jan 19, 2021 at 12:10:33AM +, David Howells wrote:
>
> From: Tianjia Zhang
>
> On the following call path, `sig->pkey_algo` is not assigned
> in asymmetric_key_verify_signature(), which causes runtime
> crash in public_key_verify_signature().
>
> keyctl_pkey_verify
> asymmetri
This patch series is a result of running kernel crypto fuzz tests (by
enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS) on the transformations
currently supported via the Qualcomm crypto engine on sdm845. The first
four patches are fixes for various regressions found during testing. The
last two patches
This patch contains the following fixes for the supported encryption
algorithms in the Qualcomm crypto engine(CE)
1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
does not support this and the operation causes the engine to hang.
2. Return unsupported if any three keys are same f
While ctr(aes) requires the use of a special descriptor on SEC2 (see
commit 70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos")), that
special descriptor doesn't work on SEC1, see commit e738c5f15562
("powerpc/8xx: Add DT node for using the SEC engine of the MPC885").
However, the common nonsno
Talitos Security Engine AESU considers any input
data size that is not a multiple of 16 bytes to be an error.
This is not a problem in general, except for Counter mode
that is a stream cipher and can have an input of any size.
Test Manager for ctr(aes) fails on 4th test vector which has
a length o
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 want to implement, you can do so
> by:
> - having a "ecdh" implementation
totallen is used to get the size of the data to be transformed.
This is also available via nbytes or cryptlen in the qce_sha_reqctx
and qce_cipher_ctx. Similarly offset convey nothing for the supported
encryption and authentication transformations and is always 0.
Remove these two redundant paramet
src_table is unused and hence remove it from struct qce_cipher_reqctx
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/cipher.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/qce/cipher.h b/drivers/crypto/qce/cipher.h
index cffa9fc628ff..850f257d00f3 100644
--- a/drivers/c
Set the register REG_ENCR_XTS_DU_SIZE to cryptlen for AES XTS
transformation. Anything else causes the engine to return back
wrong results.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/common.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qce
If the available data to transfer is exactly a multiple of block size, save
the last block to be transferred in qce_ahash_final (with the last block
bit set) if this is indeed the end of data stream. If not this saved block
will be transferred as part of next update. If this block is not held back
Export and import interfaces save and restore partial transformation
states. The partial states were being stored and restored in struct
sha1_state for sha1/hmac(sha1) transformations and sha256_state for
sha256/hmac(sha256) transformations.This led to a bunch of corner cases
where improper state w
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 of 16 bytes to be an error.
> This is not a problem in general, except for Counter mode
> that is a stream cipher and can have an input of any size.
>
> Tes
Hi Ard,
On 1/16/2021 9:00 AM, Ard Biesheuvel wrote:
On Fri, 18 Dec 2020 at 22:07, Megha Dey wrote:
From: Kyung Min Park
Update the crc_pcl function that calculates T10 Data Integrity Field
CRC16 (CRC T10 DIF) using VPCLMULQDQ instruction. VPCLMULQDQ instruction
with AVX-512F adds EVEX encode
Hi Ard,
On 1/16/2021 9:03 AM, Ard Biesheuvel wrote:
On Fri, 18 Dec 2020 at 22:08, Megha Dey wrote:
Introduce the "by16" implementation of the AES CTR mode using AVX512
optimizations. "by16" means that 16 independent blocks (each block
being 128 bits) can be ciphered simultaneously as opposed t
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 X.509. The parsing result will be set to the eku flag
> which is carried by public key. It can be used in the PKCS#7
> verification.
>
> Signed-off-b
On Wed, Jan 20, 2021 at 03:13:11PM -0700, Eric Snowberg wrote:
>
> > On Jan 20, 2021, at 4:26 AM, Jarkko Sakkinen wrote:
> >
> > On Fri, Jan 15, 2021 at 09:49:02AM -0700, Eric Snowberg wrote:
> >>
> >>> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
> >>>
> >>> On Wed, Jan 13, 2021 at 05
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 X.509. The parsing result will be set to the eku flag
> > which is
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
introduced a new tasklet initialization API. This series converts
all the crypto modules to use the new tasklet_setup() API
The series is based on v5.11-rc4 (19c329f68089)
v4:
- added acks
- fixed checkpatch e
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Romain Perier
Signed-off-by: A
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Allen Pais
---
drivers/crypto/marvell/octeontx/otx_cptvf_mai
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Acked-by: John Allen
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
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-hashes.awk script to make sure that the
> >> builti
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Reviewed-by: Horia Geantă
Signed-off-by: Romain Perier
Signed-off-by: Allen
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
On Wed, Jan 20, 2021 at 12:17:28PM +0100, Mickaël Salaün wrote:
>
> On 20/01/2021 06:15, Jarkko Sakkinen wrote:
> > On Thu, Jan 14, 2021 at 04:19:04PM +0100, Mickaël Salaün wrote:
> >> From: Mickaël Salaün
> >>
> >> Align with the new macros and add appropriate include files.
> >>
> >> Cc: David
The cesa driver mixes use of iomem pointers and normal kernel
pointers. Sometimes it uses memcpy_toio/memcpy_fromio on both
while other times it would use straight memcpy on both, through
the sg_pcopy_* helpers.
This patch fixes this by adding a new field sram_pool to the engine
for the normal po
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 of 16 bytes to be an error.
This is not a problem in general, except for Counter mode
that is a stream ciph
On 19/1/21 5:09 am, João Fonseca wrote:
Toke Høiland-Jørgensen wrote:
David Howells writes:
Toke Høiland-Jørgensen wrote:
Reviewed-by: Toke Høiland-Jørgensen
and also, if you like:
Tested-by: Toke Høiland-Jørgensen
Thanks!
Any chance of that patch getting into -stable anytime soon?
On Wed, Jan 20, 2021 at 12:15:10PM +0100, Mickaël Salaün wrote:
>
> On 20/01/2021 04:55, Jarkko Sakkinen wrote:
> > On Thu, Jan 14, 2021 at 04:19:03PM +0100, Mickaël Salaün wrote:
> >> From: David Howells
> >>
> >> KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or key_alloc(),
> >> as
On Wed, Jan 20, 2021 at 12:12:50PM +0100, Mickaël Salaün wrote:
>
> On 20/01/2021 04:43, Jarkko Sakkinen wrote:
> > On Thu, Jan 14, 2021 at 04:19:01PM +0100, Mickaël Salaün wrote:
> >> From: Mickaël Salaün
> >>
> >> When looking for a blacklisted hash, bin2hex() is used to transform a
> >> binary
> On Jan 20, 2021, at 4:26 AM, Jarkko Sakkinen wrote:
>
> On Fri, Jan 15, 2021 at 09:49:02AM -0700, Eric Snowberg wrote:
>>
>>> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
>>>
>>> On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrote:
> On Jan 13, 2021, at 1:41 PM,
Hi Ard,
On 1/16/2021 9:16 AM, Ard Biesheuvel wrote:
On Fri, 18 Dec 2020 at 22:08, Megha Dey wrote:
Introduce the AVX512 implementation that optimizes the AESNI-GCM encode
and decode routines using VPCLMULQDQ.
The glue code in AESNI module overrides the existing AVX2 GCM mode
encryption/decryp
Hi Ard,
On 1/16/2021 8:54 AM, Ard Biesheuvel wrote:
On Fri, 18 Dec 2020 at 22:07, Megha Dey wrote:
This is a preparatory patch to introduce the optimized crypto algorithms
using AVX512 instructions which would require VAES and VPLCMULQDQ support.
Check for VAES and VPCLMULQDQ assembler suppor
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 of 16 bytes to be an error.
63 matches
Mail list logo
