On Fri, Jun 26, 2020 at 02:09:39PM -0500, Tom Lendacky wrote:
> From: Tom Lendacky
>
> Add John Allen as a new CCP driver maintainer. Additionally, break out
> the driver SEV support and create a new maintainer entry, with Brijesh
> Singh and Tom Lendacky as maintainers.
>
> Cc: John Allen
> Cc
Fenghua Yu wrote:
> PASID is defined as "int" although it's a 20-bit value and shouldn't be
> negative int. To be consistent with PASID type in iommu, define PASID
> as "u32".
>
> Suggested-by: Thomas Gleixner
> Signed-off-by: Fenghua Yu
> ---
> PASID type will be changed consistently as u32:
>
On Mon, Jun 22, 2020 at 03:24:02PM -0500, John Allen wrote:
> Running the crypto manager self tests with
> CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
> when using the ccp-crypto driver:
>
> alg: skcipher: cbc-des3-ccp encryption failed on test vector 0;
> expected_err
On Mon, Jun 22, 2020 at 10:40:08AM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a corresponding decrement is
> needed on the error handling path to keep the counter balanced.
>
> Fix this by adding the missed
On Mon, Jun 22, 2020 at 11:45:03AM +0530, Sivaprakash Murugesan wrote:
> while running tcrypto test cases on qce crypto engine few failures are
> noticed, this is mainly because of the updates on tcrypto driver and
> not testing qce reqgularly with mainline tcrypto driver.
>
> This series tries to
On Mon, Jun 22, 2020 at 04:24:33PM -0700, Jian Cai wrote:
> Clang's integrated assembler complains "invalid reassignment of
> non-absolute variable 'var_ddq_add'" while assembling
> arch/x86/crypto/aes_ctrby8_avx-x86_64.S. It was because var_ddq_add was
> reassigned with non-absolute values several
This patch fixes a number of endianness marking issues in the ccp
driver.
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 82ac4c14c04c..7838f63bab32 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Friday, July 3, 2020 4:11 PM
> To: Song Bao Hua (Barry Song)
> Cc: da...@davemloft.net; Wangzhou (B) ;
> Jonathan Cameron ;
> a...@linux-foundation.org; linux-crypto@vger.kernel.org;
> linux...@kvack.or
On Fri, Jun 26, 2020 at 06:32:06PM +0800, Longfang Liu wrote:
> From: Kai Ye
>
> As before, if a SEC queue is at the 'fake busy' status,
> the request with a 'fake busy' flag will be sent into hardware
> and the sending function returns busy. After the request is
> finished, SEC driver's call bac
On Tue, Jun 23, 2020 at 04:16:08PM +1200, Barry Song wrote:
>
> -void *crypto_create_tfm(struct crypto_alg *alg,
> - const struct crypto_type *frontend)
> +void *crypto_create_tfm_node(struct crypto_alg *alg,
> + const struct crypto_type *frontend,
> +
Hi All,
We are executing a ping test in TUNNEL mode. This is to test PMTU. The test
configurations are as below.
IP address of our device: 3000::268:ebff:fe85:539f
IP address of Host1 : 3002::200:10ff:fe10:1280
SGW (Gateway address): 3001::200:10ff:fe10:1161
1. SGW send
Hi All,
We are executing a simple ping test on our device in transport mode. Test
configuration and steps are as below
IP address of Host-1=> 3001::200:10ff:fe10:1180
IP address of our device=> 3000::268:ebff:fe85:539f
1.
2 pair of SA's are established.
HOST1_Link
On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
> >
> > [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
> >
> > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> > > Remove the generic ecb(arc4) skcipher, which is sligh
On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
>
> [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
>
> On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
> > a maintenance perspective, since it does n
[+linux-wireless, Marcel Holtmann, and Denis Kenzior]
On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
> a maintenance perspective, since it does not quite behave like other
> skciphers do in terms of key vs
Allow padata_do_multithreaded function to be called after bootstrap.
v2: removed __init from padata_work_alloc_mt and padata_works_free
Signed-off-by: Nico Pache
---
include/linux/padata.h | 2 +-
kernel/padata.c| 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --
Acked-by: J. Bruce Fields
On Thu, Jul 02, 2020 at 12:19:43PM +0200, Ard Biesheuvel wrote:
> The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
> was specifically issued for interoperability with Windows 2000, but was
> never intended to receive the same level of support. The RFC
Hi Nico,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.8-rc3 next-20200702]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as
On Thu, Jul 02, 2020 at 12:19:41PM +0200, Ard Biesheuvel wrote:
> Switch to the ARC4 library interface, to remove the pointless
> dependency on the skcipher API, from which we will hopefully be
> able to drop ecb(arc4) skcipher support.
>
> Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hart
On Thu, Jul 02, 2020 at 12:19:42PM +0200, Ard Biesheuvel wrote:
> Switch to the ARC4 library interface, to remove the pointless
> dependency on the skcipher API, from which we will hopefully be
> able to drop ecb(arc4) skcipher support.
>
> Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hart
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers/staging/rtl8192e/rtllib_crypt_tki
The RC4 algorithm does not fit the sckipher model very well: it is a stream
cipher that combines the key and IV into a single vector, which implies that
using the same key more than once amounts to stream cipher IV reuse, and
therefore catastrophic failure.
So let's replace the remaining legacy us
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 21 +--
crypto/testmgr.c | 7 ---
crypto/testmgr.h | 62
3 files changed, 1 insertion(+), 89 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index ba0b7702f2e9..72828c4acd3a 100644
--- a/crypto/tcrypt.c
++
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192u/Kconfig | 1 +
drivers/staging/rtl8192u/ieee
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6 ins
Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
a maintenance perspective, since it does not quite behave like other
skciphers do in terms of key vs IV lifetime. Since we are leaving the
library interface in place, which is used by the various WEP and TKIP
implementations w
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 6a828bbecea4..c347e58cd9a1 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7 +
The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
was specifically issued for interoperability with Windows 2000, but was
never intended to receive the same level of support. The RFC says
The IETF Kerberos community supports publishing this specification as
an informational
On Wed, Jul 1, 2020 at 11:48 PM Rikard Falkeborn
wrote:
>
> Constify some static variables (mostly structs) that are not modified.
>
> Rikard Falkeborn (5):
> hwrng: bcm2835 - Constify bcm2835_rng_devtype[]
> hwrng: nomadik - Constify nmk_rng_ids[]
> hwrng: virtio - Constify id_table[]
> i
On 20-06-21 17:56, Horia Geantă wrote:
> i.MX6 SL, SLL, ULL, ULZ SoCs have an RNGB block.
>
> Since imx-rngc driver supports also rngb,
> let's enable it for these SoCs too.
>
> Signed-off-by: Horia Geantă
> ---
Reviewed-by: Marco Felsch
On 20-06-21 17:56, Horia Geantă wrote:
> Add node for the RNGB block.
>
> Signed-off-by: Horia Geantă
> ---
Reviewed-by: Marco Felsch
On Thu, 2 Jul 2020 at 09:56, Herbert Xu wrote:
>
> On Thu, Jul 02, 2020 at 09:51:29AM +0200, Ard Biesheuvel wrote:
> >
> > I'll wait for the code to be posted (please put me on cc), but my
>
> Sure I will.
>
> > suspicion is that carrying opaque state like that is going to bite us
> > down the roa
On Thu, Jul 02, 2020 at 05:56:16PM +1000, Herbert Xu wrote:
>
> For XTS I haven't decided whether to go this way or not. If it
> does work out though we could even extend it to AEAD.
But there is clearly a need for this functionality, and it's
not just af_alg. Have a look at net/sunrpc/auth_gss/
On Thu, Jul 02, 2020 at 09:51:29AM +0200, Ard Biesheuvel wrote:
>
> I'll wait for the code to be posted (please put me on cc), but my
Sure I will.
> suspicion is that carrying opaque state like that is going to bite us
> down the road.
Well it's only going to be arc4 at first, where it's definit
On Wed, Jul 1, 2020 at 11:48 PM Rikard Falkeborn
wrote:
>
> nmk_rng_ids[] is not modified and can be made const to allow the
> compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
> 652 216 4 872 368 drivers/char/hw_random/nom
On Thu, 2 Jul 2020 at 09:45, Herbert Xu wrote:
>
> On Thu, Jul 02, 2020 at 09:40:42AM +0200, Ard Biesheuvel wrote:
> >
> > I suppose you are looking into this for chaining algif_skipcher
> > requests, right? So in that case, the ARC4 state should really be
> > treated as an IV, which is owned by t
On Thu, Jul 02, 2020 at 09:40:42AM +0200, Ard Biesheuvel wrote:
>
> I suppose you are looking into this for chaining algif_skipcher
> requests, right? So in that case, the ARC4 state should really be
> treated as an IV, which is owned by the caller, and not stored in
> either the TFM or the skciphe
On Thu, Jul 02, 2020 at 09:32:32AM +0200, Ard Biesheuvel wrote:
>
> Actually, it seems the generic ecb(arc4) is broken as well in this regard.
Not in the same way. The generic arc4 stores the state in the
tfm so it works until you have two requests that share the same
tfm.
Since we only have two
On Thu, Jul 02, 2020 at 09:27:33AM +0200, Ard Biesheuvel wrote:
>
> I do wonder if the others are doing any better - n2 and bcm iproc also
> appear to keep the state in the TFM object, while I'd expect the
> setkey() to be a simple memcpy(), and the initial state derivation to
> be part of the enc
On Thu, 2 Jul 2020 at 09:32, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 09:27, Ard Biesheuvel wrote:
> >
> > On Thu, 2 Jul 2020 at 06:36, Herbert Xu wrote:
> > >
> > > The arc4 algorithm requires storing state in the request context
> > > in order to allow more than one encrypt/decrypt oper
On Thu, 2 Jul 2020 at 09:27, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 06:36, Herbert Xu wrote:
> >
> > The arc4 algorithm requires storing state in the request context
> > in order to allow more than one encrypt/decrypt operation. As this
> > driver does not seem to do that, it means that
On Thu, 2 Jul 2020 at 06:36, Herbert Xu wrote:
>
> The arc4 algorithm requires storing state in the request context
> in order to allow more than one encrypt/decrypt operation. As this
> driver does not seem to do that, it means that using it for more
> than one operation is broken.
>
> Fixes: ea
42 matches
Mail list logo
