On Mon, Mar 01, 2021 at 09:51:56PM +0100, Christoph Böhmwalder wrote:
> > Do you have a specific use case in mind for this information? Normally,
> > users
> > should already know which algorithm they want to use (or set of algorithms
> > they
> > might want to use).
>
> I have a pretty specifi
On 2/26/21 10:35 PM, yumeng wrote:
在 2021/2/26 0:08, Stefan Berger 写道:
From: Stefan Berger
diff --git a/certs/Makefile b/certs/Makefile
index 3fe6b73786fa..c487d7021c54 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -69,6 +69,18 @@ else
SIGNER = -signkey $(obj)/signing_key.key
end
On 01.03.21 19:47, Eric Biggers wrote:
On Mon, Mar 01, 2021 at 05:59:17PM +0100, Christoph Böhmwalder wrote:
Currently, it is not apparent for userspace users which hash algorithms
require a key and which don't. We have /proc/crypto, so add a field
with this information there.
Signed-off-by: Ch
On Mon, Mar 01, 2021 at 05:59:17PM +0100, Christoph Böhmwalder wrote:
> Currently, it is not apparent for userspace users which hash algorithms
> require a key and which don't. We have /proc/crypto, so add a field
> with this information there.
>
> Signed-off-by: Christoph Böhmwalder
>
> ---
>
On Sun, Feb 28, 2021 at 01:28:24PM +0100, Ard Biesheuvel wrote:
> Given that crypto_alloc_tfm() may return ERR pointers, and to avoid
> crashes on obscure error paths where such pointers are presented to
> crypto_destroy_tfm() (such as [0]), add an ERR_PTR check there
> before dereferencing the sec
From: Eric Biggers
commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream.
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc:
From: Eric Biggers
commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream.
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc:
From: Eric Biggers
commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream.
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc:
Currently, it is not apparent for userspace users which hash algorithms
require a key and which don't. We have /proc/crypto, so add a field
with this information there.
Signed-off-by: Christoph Böhmwalder
---
crypto/shash.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/shash.c b
From: Eric Biggers
commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream.
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc:
From: Eric Biggers
commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream.
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc:
From: Eric Biggers
commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream.
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc:
Hi All,
I am on a Layerscape LS1046a using Linux-5.11. The CAAM driver sometimes
crashes during the run-time self tests with:
> kernel BUG at drivers/crypto/caam/jr.c:247!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 5.11.0-2
On Sat, 2021-02-27 at 11:35 +0800, yumeng wrote:
> 在 2021/2/26 0:08, Stefan Berger 写道:
> > From: Stefan Berger
> >
>
> > diff --git a/certs/Makefile b/certs/Makefile
> > index 3fe6b73786fa..c487d7021c54 100644
> > --- a/certs/Makefile
> > +++ b/certs/Makefile
> > @@ -69,6 +69,18 @@ else
> > SI
Le 01/03/2021 à 11:30, Yang Li a écrit :
Rename kfree() to kfree_sensitive() to make the intention of the API
more explicit.
As far as I understand, you are not renaming kfree() to kfree_sensitive().
You are making a change to use kfree_sensitive() instead of using kfree().
Christophe
On Mon, Mar 01, 2021 at 06:30:41PM +0800, Yang Li wrote:
> Rename kfree() to kfree_sensitive() to make the intention of the API
> more explicit.
>
> fixed the following coccicheck:
> ./drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c:30:16-17: WARNING
> opportunity for kfree_sensitive/kvfree_sen
Rename kfree() to kfree_sensitive() to make the intention of the API
more explicit.
fixed the following coccicheck:
./drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c:30:16-17: WARNING
opportunity for kfree_sensitive/kvfree_sensitive (memset at line 29)
./drivers/crypto/allwinner/sun8i-ce/sun8i-
Hi Hui,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on crypto/master v5.12-rc1 next-20210301]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
18 matches
Mail list logo
