Hi all,
Commit
50d7e084c48d ("crypto: hisilicon/hpre - add initial settings adapt to
'Kunpeng 930'")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpPhpRxHzzHz.pgp
Description: OpenPGP digital signature
On Fri, 13 Nov 2020 at 06:21, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Currently contains declarations for both SHA-1 and SHA-2,
> and contains declarations for SHA-3.
>
> This organization is inconsistent, but more importantly SHA-1 is no
> longer considered to be cryptographically secur
On Fri, Nov 13, 2020 at 01:56:46PM +0800, kernel test robot wrote:
>
> All warnings (new ones prefixed by >>):
>
> >> lib/crypto/curve25519-selftest.c:1283:13: warning: no previous prototype
> >> for 'curve25519_selftest' [-Wmissing-prototypes]
> 1283 | bool __init curve25519_selftest(void)
>
From: Eric Biggers
Currently contains declarations for both SHA-1 and SHA-2,
and contains declarations for SHA-3.
This organization is inconsistent, but more importantly SHA-1 is no
longer considered to be cryptographically secure. So to the extent
possible, SHA-1 shouldn't be grouped togethe
On Tue, Nov 03, 2020 at 05:28:09PM +0100, Ard Biesheuvel wrote:
> The current NEON based ChaCha implementation for ARM is optimized for
> multiples of 4x the ChaCha block size (64 bytes). This makes sense for
> block encryption, but given that ChaCha is also often used in the
> context of networkin
On Fri, Nov 06, 2020 at 07:27:38PM +0800, Jack Xu wrote:
> Rework firmware loader in QAT driver in preparation for the support of the
> qat_4xxx driver.
>
> Patch #1 add support for the mof format in the firmware loader
> Patches from #2 to #7 introduce some general fixes
> Patches from #8 to #30
On Fri, Nov 06, 2020 at 05:39:38PM +0100, Ard Biesheuvel wrote:
> Based on lessons learnt from optimizing the 32-bit version of this driver,
> we can simplify the arm64 version considerably, by reordering the final
> two stores when the last block is not a multiple of 64 bytes. This removes
> the n
On Tue, Nov 03, 2020 at 05:29:36PM +, Giovanni Cabiddu wrote:
> From: Adam Guerin
>
> Change all lower case pci in comments to be upper case PCI.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Adam Guerin
> Reviewed-by: Giovanni Cabiddu
> Reviewed-by: Andy Shevchenko
> Signed-off-by:
On Mon, Nov 02, 2020 at 02:48:15PM +0100, Jason A. Donenfeld wrote:
> The extra tests in the manager actually require the manager to be
> selected too. Otherwise the linker gives errors like:
>
> ld: arch/x86/crypto/chacha_glue.o: in function `chacha_simd_stream_xor':
> chacha_glue.c:(.text+0x422)
On Mon, Nov 02, 2020 at 05:04:54PM +, Giovanni Cabiddu wrote:
> From: Adam Guerin
>
> Remove cast for mailbox CSR in adf_admin.c as it is not needed.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Adam Guerin
> Reviewed-by: Giovanni Cabiddu
> Reviewed-by: Andy Shevchenko
> Signed-off
On Mon, Nov 02, 2020 at 10:31:05AM +0800, Meng Yu wrote:
> Enable 'CURVE25519' algorithm in 'Kunpeng 930'.
>
> Signed-off-by: Meng Yu
> Reviewed-by: Zaibo Xu
> Reported-by: kernel test robot
> ---
> drivers/crypto/hisilicon/hpre/hpre.h| 2 +
> drivers/crypto/hisilicon/hpre/hpre_crypt
On Fri, Nov 13, 2020 at 02:39:24PM +1100, Herbert Xu wrote:
> Horia Geantă wrote:
> >
> > -- >8 --
> >
> > Subject: [PATCH] crypto: caam/qi - simplify error path for context
> > allocation
>
> You can't do this. Patchwork takes any replies with the same
> Subject line as a comment.
>
> You ne
Horia Geantă wrote:
>
> -- >8 --
>
> Subject: [PATCH] crypto: caam/qi - simplify error path for context allocation
You can't do this. Patchwork takes any replies with the same
Subject line as a comment.
You need to resend this patch with a different subject.
Thanks,
--
Email: Herbert Xu
Hom
On Wed, Nov 11, 2020 at 04:10:39PM -0800, Jakub Kicinski wrote:
> On Mon, 9 Nov 2020 17:39:24 +0530 Srujana Challa wrote:
> > CPT offload module utilises the linux crypto framework to offload
> > crypto processing. This patch registers supported algorithms by
> > calling registration functions prov
On Thu, Nov 12, 2020 at 10:21:35PM +0100, Christian Lamparter wrote:
> Hello,
>
> On 12/11/2020 21:07, Nathan Chancellor wrote:
> > Clang warns:
> >
> > drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has
> > lower precedence than '|'; '|' will be evaluated first
> > [-Wbitwis
Hello,
On 12/11/2020 21:07, Nathan Chancellor wrote:
Clang warns:
drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has
lower precedence than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
(crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYP
Hi Konrad,
On Thu, Nov 12, 2020 at 09:26:30PM +0100, Konrad Dybcio wrote:
> Hi Eric,
>
> First of all, I am EXTREMELY sorry for my long overdue response..
>
> I just wanted to bring up that piece of HW so as to offload crypto
> tasks from the CPU, but it ended up being slower (which I suspect is
> On Nov 12, 2020, at 4:07 PM, Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
>> Chuck Lever wrote:
>>
>>> Really? My understanding of the Linux kernel SUNRPC implementation is
>>> that it uses asynchronous, even for small data items. Maybe I'm using
>
On Thu, Nov 12, 2020 at 04:54:06PM +, David Howells wrote:
> Chuck Lever wrote:
>
> > Really? My understanding of the Linux kernel SUNRPC implementation is
> > that it uses asynchronous, even for small data items. Maybe I'm using
> > the terminology incorrectly.
>
> Seems to be synchronous,
Hi Eric,
First of all, I am EXTREMELY sorry for my long overdue response..
I just wanted to bring up that piece of HW so as to offload crypto
tasks from the CPU, but it ended up being slower (which I suspect is
due to bw scaling not being implemented, but I might be wrong, maybe
A53+crypto is jus
Clang warns:
drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has
lower precedence than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
(crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ?
~~
> On Nov 12, 2020, at 1:37 PM, J. Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>>
>> Hi Herbert, Bruce,
>>
>> Here's my first cut at a generic Kerberos crypto library in the kernel so
>> that I can share code between rxrpc and sunrpc (and cifs?).
>>
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added
Chuck Lever wrote:
> Really? My understanding of the Linux kernel SUNRPC implementation is
> that it uses asynchronous, even for small data items. Maybe I'm using
> the terminology incorrectly.
Seems to be synchronous, at least in its use of skcipher:
grep -e skcipher *
gss_krb5_crypto.c:#inclu
On Thu, 12 Nov 2020 07:07:34 + Srujana Challa wrote:
> > On Mon, 9 Nov 2020 17:39:17 +0530 Srujana Challa wrote:
> > > + err = pci_alloc_irq_vectors(pdev, RVU_PF_INT_VEC_CNT,
> > > + RVU_PF_INT_VEC_CNT, PCI_IRQ_MSIX);
> >
> > I don't see any pci_free_irq_vectors
> On Nov 12, 2020, at 10:42 AM, David Howells wrote:
>
> Chuck Lever wrote:
>
>>> There are three main interfaces to it:
>>>
>>> (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
>>>
>>>These all do in-place crypto, using an sglist to define the buffer
>>>with the data in i
Chuck Lever wrote:
> > There are three main interfaces to it:
> >
> > (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
> >
> > These all do in-place crypto, using an sglist to define the buffer
> > with the data in it. Is it necessary to make it able to take separate
> > i
> On Nov 12, 2020, at 7:57 AM, David Howells wrote:
>
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added more
Would it be possible/practical to make the skcipher encrypt functions take an
offset into the scatterlist rather than always starting at the beginning?
David
---
net/rxrpc/ar-internal.h |1
net/rxrpc/key.c | 136 +++
net/rxrpc/rxgk.c| 25 +
net/rxrpc/rxgk_app.c| 135 +++
net/rxrpc/rxgk_common.h |2 +
net/rxrpc/security.c
Provide key derivation interface functions and a helper to implement the
PRF+ function from rfc4402.
Signed-off-by: David Howells
---
crypto/krb5/Makefile |1
crypto/krb5/kdf.c | 223 +
include/crypto/krb5.h | 29 ++
3 files chang
Add some constants from the sunrpc headers.
Signed-off-by: David Howells
---
include/crypto/krb5.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/include/crypto/krb5.h b/include/crypto/krb5.h
index 2bd6cfe50b85..a7e4ab4e1348 100644
--- a/include/c
Implement rekeying of connections with the RxGK security class. This
involves regenerating the keys with a different key number as part of the
input data after a certain amount of time or a certain amount of bytes
encrypted. Rekeying may be triggered by either end.
The LSW of the key number is i
Provide some infrastructure for implementing the RxGK transport security
class:
(1) A definition of an encoding type, including:
- Relevant crypto-layer names
- Lengths of the crypto keys and checksums involved
- Crypto functions specific to the encoding type
- Cr
Add support for the YFS-variant RxGK security class to support
GSSAPI-derived authentication. This also allows the use of better crypto
over the rxkad security class.
The key payload is XDR encoded of the form:
typedef int64_t opr_time;
const AFSTOKEN_RK_TIX_MAX = 12000; /* Matches ent
Implement the basic parts of the yfs-rxgk security class (security index 6)
to support GSSAPI-negotiated security.
Signed-off-by: David Howells
---
include/trace/events/rxrpc.h |4
net/rxrpc/Makefile |2
net/rxrpc/ar-internal.h | 12
net/rxrpc/rxgk.c | 10
Add the security index for the YFS variant of rxgk.
Signed-off-by: David Howells
---
fs/afs/misc.c | 13 +
include/uapi/linux/rxrpc.h | 17 +
2 files changed, 30 insertions(+)
diff --git a/fs/afs/misc.c b/fs/afs/misc.c
index 1d1a8debe472..796783774e
Implement the camellia128-cts-cmac and camellia256-cts-cmac enctypes from
rfc6803.
Note that the test vectors in rfc6803 for encryption are incomplete,
lacking the key usage number needed to derive Ke and Ki, and there are
errata for this:
https://www.rfc-editor.org/errata_search.php?rfc=
Implement encryption and decryption functions for AES + HMAC-SHA2 as
described in rfc8009 sec 5.
Signed-off-by: David Howells
---
crypto/krb5/rfc8009_aes2.c | 205
1 file changed, 203 insertions(+), 2 deletions(-)
diff --git a/crypto/krb5/rfc8009_a
Implement the aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192
enctypes from rfc8009, overriding the rfc3961 kerberos 5 simplified crypto
scheme.
Signed-off-by: David Howells
---
crypto/krb5/Kconfig|2
crypto/krb5/Makefile |3 -
crypto/krb5/internal.h |6
Add the self-testing data from rfc8009 to test AES + HMAC-SHA2.
Signed-off-by: David Howells
---
crypto/krb5/selftest_data.c | 116 +++
1 file changed, 116 insertions(+)
diff --git a/crypto/krb5/selftest_data.c b/crypto/krb5/selftest_data.c
index 908572
Implement self-testing infrastructure to test the pseudo-random function,
key derivation, encryption and checksumming.
Signed-off-by: David Howells
---
crypto/krb5/Kconfig |4
crypto/krb5/Makefile|4
crypto/krb5/internal.h | 48
crypto/krb5/main.c
Implement the aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 enctypes
from rfc3962, using the rfc3961 kerberos 5 simplified crypto scheme.
Signed-off-by: David Howells
---
crypto/krb5/Makefile |3 +
crypto/krb5/internal.h|6 ++
crypto/krb5/main.c|2 +
crypto/kr
Add functions that sign and verify a piece of an skbuff according to
rfc3961 sec 5.4, using Kc to generate a checksum and insert it into the MIC
field in the skbuff in the sign phase then checksum the data and compare it
to the MIC in the verify phase.
Signed-off-by: David Howells
---
crypto/kr
Add functions that encrypt and decrypt a piece of an skbuff according to
rfc3961 sec 5.3, using Ki to checksum the data to be secured and Ke to
encrypt it during the encryption phase, then decrypting with Ke and
verifying the checksum with Ki in the decryption phase.
Signed-off-by: David Howells
Implement the simplified crypto profile for Kerberos 5 rfc3961 with the
pseudo-random function, PRF(), from section 5.3 and the key derivation
function, DK() from section 5.1.
Signed-off-by: David Howells
---
crypto/krb5/Makefile |3
crypto/krb5/internal.h |6 +
c
Hi Herbert, Bruce,
Here's my first cut at a generic Kerberos crypto library in the kernel so
that I can share code between rxrpc and sunrpc (and cifs?).
I derived some of the parts from the sunrpc gss library and added more
advanced AES and Camellia crypto. I haven't ported across the DES-base
Provide core structures, an encoding-type registry and basic module and
config bits for a generic Kerberos crypto library.
Signed-off-by: David Howells
---
crypto/Kconfig |1 +
crypto/Makefile|1 +
crypto/krb5/Kconfig| 11 ++
crypto/krb5/Makefile |9 +
On Thu, Nov 12, 2020 at 03:20:53PM +0800, Li Qiang wrote:
>
>
> 在 2020/11/11 0:07, Dave Martin 写道:
> > add zA.s, pP/m, zA.s, zX.s// zA.s += zX.s
> >
> > msb zX.s, pP/m, zJ.s, zB.s// zX.s := zB.s - zX.s *
> > zJ.s
> >
> > mov
Hi,
running 5.10-rc3, I have come across a null pointer dereference.
It occured while trying to connect to a 802.1x/EAP-protected network using iwd.
However, the bug seems to be limited to iwd's usage of the keyctl API
(unrelated to the wireless subsystem).
The bug seems related to the recent ch
On Wed, Nov 11, 2020 at 8:19 AM Ard Biesheuvel wrote:
>
> I am still not convinced we need this change, as I don't see how the
> concerns regarding __section apply to __alias. But if we do, can we
> please use the same approach, i.e., revert the current patch, and
> queue it again after v5.11-rc1
On 11/6/2020 11:01 AM, Wang Qing wrote:
> Fix passing zero to 'PTR_ERR' warning
>
Thanks.
> Signed-off-by: Wang Qing
> ---
> drivers/crypto/caam/caamalg_qi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/caam/caamalg_qi.c
> b/drivers/crypto/caam/caama
On Wed, 11 Nov 2020 at 18:46, Ondrej Mosnáček wrote:
>
> ut 10. 11. 2020 o 20:04 Ard Biesheuvel napísal(a):
> > Wiring the SIMD code into the generic driver has the unfortunate side
> > effect that the tcrypt testing code cannot distinguish them, and will
> > therefore not use the latter to fuzz
53 matches
Mail list logo
