On Wed, Jun 10, 2020 at 09:14:34AM -0700, Eric Biggers wrote:
> This series consolidates and modernizes the lists of crypto algorithms
> that are selected by the IPsec kconfig options, and adds CRYPTO_SEQIV
> since it no longer gets selected automatically by other things.
>
> See previous discussi
On 2020/6/8 22:01, Longfang Liu Wrote:
> As stress-ng running SEC engine on the Ubuntu OS,
> we found that SEC only supports two threads each with one TFM
> based on the default module parameter 'ctx_q_num'.
> If running more threads, stress-ng will fail since it cannot
> get more TFMs.
>
> In orde
On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote:
> On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > > v4:
> > > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > > so that it can
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary me
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I worked on adding a 'free' a couple
On 6/16/20 2:53 PM, Joe Perches wrote:
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
v4:
- Break out the memzero_explicit() change as suggested by Dan Carpenter
so that it can be backported to stable.
- Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches wrote:
>
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary memzero_
On 6/16/20 2:53 PM, Joe Perches wrote:
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
v4:
- Break out the memzero_explicit() change as suggested by Dan Carpenter
so that it can be backported to stable.
- Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> v4:
> - Break out the memzero_explicit() change as suggested by Dan Carpenter
> so that it can be backported to stable.
> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> now as there can be a bit more discus
On 6/16/20 2:09 PM, Andrew Morton wrote:
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long wrote:
As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.
In "kzalloc()", the z is meaningful and an important part of what
On Tue, Jun 16, 2020 at 02:18:17PM -0400, Mikulas Patocka wrote:
>
>
> On Tue, 16 Jun 2020, Eric Biggers wrote:
>
> > On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > > Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
> > > CRYPTO_TFM_REQ_MAY_SLEEP is no
On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
> > CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
> > that sleeps.
> >
> > Signed-off-
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long wrote:
> As said by Linus:
>
> A symmetric naming is only helpful if it implies symmetries in use.
> Otherwise it's actively misleading.
>
> In "kzalloc()", the z is meaningful and an important part of what the
> caller wants.
>
> In "kz
On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
> CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
> that sleeps.
>
> Signed-off-by: Mikulas Patocka
I think you need to split this up p
On Tue, Jun 16, 2020 at 11:02:20AM -0400, Mikulas Patocka wrote:
> Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
> allocate memory.
>
> Signed-off-by: Mikulas Patocka
>
> ---
> drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c |8 +-
> drivers/crypto/allwinner/sun8i-ss
On Tue, Jun 16, 2020 at 11:01:58AM -0400, Mikulas Patocka wrote:
> Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
>
> Signed-off-by: Mikulas Patocka
>
> ---
> crypto/adiantum.c |3 ++-
> crypto/authenc.c |5 +++--
> crypto/authencesn.c |
On Tue, Jun 16, 2020 at 11:01:31AM -0400, Mikulas Patocka wrote:
> Introduce a new flag CRYPTO_ALG_ALLOCATES_MEMORY and modify dm-crypt, so
> that it uses only drivers without this flag.
>
> If the flag is set, then the crypto driver allocates memory in its request
> routine. Such drivers are not
On Tue, Jun 16, 2020 at 09:04:44PM +1000, Herbert Xu wrote:
> On Mon, Jun 15, 2020 at 11:50:28AM -0700, Eric Biggers wrote:
> >
> > Wouldn't it make a lot more sense to make skcipher algorithms non-chainable
> > by
> > default, and only opt-in the ones where chaining is actually working? At
> >
On Tue, Jun 16, 2020 at 08:02:58AM +0200, Steffen Klassert wrote:
> On Mon, Jun 15, 2020 at 03:13:15PM -0700, Eric Biggers wrote:
> > This series consolidates and modernizes the lists of crypto algorithms
> > that are selected by the IPsec kconfig options, and adds CRYPTO_SEQIV
> > since it no long
From: Daniel Jordan
[ Upstream commit 3c2214b6027ff37945799de717c417212e1a8c54 ]
Removing the pcrypt module triggers this:
general protection fault, probably for non-canonical
address 0xdead0122
CPU: 5 PID: 264 Comm: modprobe Not tainted 5.6.0+ #2
Hardware name: QEMU Standard
v5:
- Break the btrfs patch out as a separate patch to be processed
independently.
- Update the commit log of patch 1 to make it less scary.
- Add a kzfree backward compatibility macro in patch 2.
v4:
- Break out the memzero_explicit() change as suggested by Dan Carpenter
so that
The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for buffer clearing. However
unlikely, there is still a non-zero probability that the compiler may
choose to optimize away t
From: Daniel Jordan
[ Upstream commit 3c2214b6027ff37945799de717c417212e1a8c54 ]
Removing the pcrypt module triggers this:
general protection fault, probably for non-canonical
address 0xdead0122
CPU: 5 PID: 264 Comm: modprobe Not tainted 5.6.0+ #2
Hardware name: QEMU Standard
As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.
In "kzalloc()", the z is meaningful and an important part of what the
caller wants.
In "kzfree()", the z is actively detrimental, because maybe in the
future we r
Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset()
"memset()" is all lowercase.
> is currently used for buffer clearing. However unlikely, there is still a
> non-ze
From: Daniel Jordan
[ Upstream commit 3c2214b6027ff37945799de717c417212e1a8c54 ]
Removing the pcrypt module triggers this:
general protection fault, probably for non-canonical
address 0xdead0122
CPU: 5 PID: 264 Comm: modprobe Not tainted 5.6.0+ #2
Hardware name: QEMU Standard
On 6/16/20 10:26 AM, Dan Carpenter wrote:
Last time you sent this we couldn't decide which tree it should go
through. Either the crypto tree or through Andrew seems like the right
thing to me.
Also the other issue is that it risks breaking things if people add
new kzfree() instances while we ar
On 6/16/20 10:48 AM, David Sterba wrote:
On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:
In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
was incorrectly paired with kzfree(). According to David Sterba, there
isn't any sensitive information in the subvol_inf
Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
allocate memory.
Signed-off-by: Mikulas Patocka
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c |8 +-
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c |8 +-
drivers/crypto/amlogic/amlogic-gxl-core.c |
Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
that sleeps.
Signed-off-by: Mikulas Patocka
---
drivers/crypto/amlogic/amlogic-gxl-cipher.c |5 ++-
drivers/crypto/cavium/cpt/cptvf_algs.c |
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |3 ++-
crypto/authenc.c |5 +++--
crypto/authencesn.c |5 +++--
crypto/ccm.c |7 ---
crypto/chacha20poly1305.c |
Introduce a new flag CRYPTO_ALG_ALLOCATES_MEMORY and modify dm-crypt, so
that it uses only drivers without this flag.
If the flag is set, then the crypto driver allocates memory in its request
routine. Such drivers are not suitable for disk encryption because
GFP_ATOMIC allocation can fail anytime
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Wed, Jun 10, 2020 at 08:02:23AM -0400, Mikulas Patocka wrote:
> >
> > Yes, fixing the drivers would be the best - but you can hardly find any
> > person who has all the crypto hardware and who is willing to rewrite all
> > the drivers for it.
>
> W
On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:
> In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
> was incorrectly paired with kzfree(). According to David Sterba, there
> isn't any sensitive information in the subvol_info that needs to be
> cleared before fr
Last time you sent this we couldn't decide which tree it should go
through. Either the crypto tree or through Andrew seems like the right
thing to me.
Also the other issue is that it risks breaking things if people add
new kzfree() instances while we are doing the transition. Could you
just add
On 6/15/20 11:30 PM, Eric Biggers wrote:
On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote:
The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for the buffer clea
On Mon, Jun 15, 2020 at 11:50:28AM -0700, Eric Biggers wrote:
>
> Wouldn't it make a lot more sense to make skcipher algorithms non-chainable by
> default, and only opt-in the ones where chaining is actually working? At the
> moment we only test iv_out for CBC and CTR, so we can expect that all th
On 15/06/2020 14:36, Herbert Xu wrote:
This patch fixes sparse endianness warnings as well as compiler
warnings on 64-bit hosts.
Signed-off-by: Herbert Xu
Looks fine to me:
Reviewed-by: Tero Kristo
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 8eda43319204..c9d
On 15/06/2020 14:37, Herbert Xu wrote:
This patch fixes sparse endianness warnings as well as compiler
warnings on 64-bit hosts.
Signed-off-by: Herbert Xu
Looks okay to me.
Reviewed-by: Tero Kristo
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 82691a057d2a..9
On 2020/6/10 4:58, Vitaly Chikunov wrote:
Tianjia,
On Tue, Jun 09, 2020 at 09:48:47PM +0800, Tianjia Zhang wrote:
Hello all,
This new module implement the OSCCA certificate and SM2 public key
algorithm. It was published by State Encryption Management Bureau, China.
List of specifications fo
On Tue, Jun 16, 2020 at 08:42:08AM +0200, Michal Hocko wrote:
> On Mon 15-06-20 21:57:16, Waiman Long wrote:
> > The kzfree() function is normally used to clear some sensitive
> > information, like encryption keys, in the buffer before freeing it back
> > to the pool. Memset() is currently used for
On Mon, Jun 15, 2020 at 03:18:54PM +0200, Lukasz Stelmach wrote:
>
> I believe this fix has already been submitted
>
>
> https://lore.kernel.org/linux-arm-kernel/20200522011659.26727-1-dinghao@zju.edu.cn/T/#u
>
> It hasn't been applied though. Anyway, thank you for your work.
>
> Herber
42 matches
Mail list logo
